[Cluster-devel] [GFS2 PATCH] gfs2: revert af21ca8ed50f01c5278c5ded6dad6f05e8a5d2e4
Steven Whitehouse
swhiteho at redhat.com
Fri Jun 1 08:41:06 UTC 2018
Hi,
On 30/05/18 20:18, Bob Peterson wrote:
> Hi,
>
> Patch af21ca8ed5 is defective and needs to be reverted. The idea
> was to only reserve single blocks for directories, with the thought
> that they should be packed together. That's all well and good for
> creating new directories, but directories have other reasons for
> getting reservations: for example, when files are added to them
> and they need their directory hash tables expanded. For
> those purposes, one block may not be enough and the reservation
> can run out of blocks, forcing us to do block allocations without
> a reservation. We can also get into situations where we cannot
> modify a directory when we should be able to.
>
> This patch reverts the patch.
>
> Signed-off-by: Bob Peterson <rpeterso at redhat.com>
Doing allocation without a reservation is ok though, since the
reservations are only hints and what really protects us against running
out of blocks is the block counts on the rgrp. I forget now what the
reason was that we couldn't add reservations for directories of more
than one block, but I had a feeling there was a reason that we did that
at the time.
That said, having reservations result in directories which are less
fragments is definitely a good thing. One issue is whether it makes
sense in case of deep directory trees which each directory itself
contains only other directories, and indeed, not a huge number (so that
the directories are still stuffed files). In that case we'll land up
with a lot of fragmentation if we are not careful and simply apply a
reservation without some knowledge of the directory size/layout.
It would be good if we could add a feature to the allocator to allocate
contiguous extents even if it means searching a bit harder, and then to
use that for directory hash tables so that we can at least keep those to
a single extent where possible. The downside is that we then land up
leaving holes where the old hash table was, which are then not easy to
reuse...
Steve.
> ---
> fs/gfs2/rgrp.c | 9 ++-------
> 1 file changed, 2 insertions(+), 7 deletions(-)
>
> diff --git a/fs/gfs2/rgrp.c b/fs/gfs2/rgrp.c
> index 8be47b81011a..d7a8ed8bb30c 100644
> --- a/fs/gfs2/rgrp.c
> +++ b/fs/gfs2/rgrp.c
> @@ -1529,14 +1529,9 @@ static void rg_mblk_search(struct gfs2_rgrpd *rgd, struct gfs2_inode *ip,
> u32 extlen;
> u32 free_blocks = rgd_free(rgd, rs);
> int ret;
> - struct inode *inode = &ip->i_inode;
>
> - if (S_ISDIR(inode->i_mode))
> - extlen = 1;
> - else {
> - extlen = max_t(u32, atomic_read(&rs->rs_sizehint), ap->target);
> - extlen = clamp(extlen, RGRP_RSRV_MINBLKS, free_blocks);
> - }
> + extlen = max_t(u32, atomic_read(&rs->rs_sizehint), ap->target);
> + extlen = clamp(extlen, RGRP_RSRV_MINBLKS, free_blocks);
> if ((rgd->rd_free_clone < rgd->rd_reserved) || (free_blocks < extlen))
> return;
>
>
>
More information about the Cluster-devel
mailing list