[Cluster-devel] [GFS2 Patch] [Try 2] GFS2: Reduce file fragmentation

[Steven Whitehouse <swhiteho@redhat.com>]

Hi,

On Wed, 2012-07-11 at 14:07 -0400, Bob Peterson wrote:
[snip]
>  
> | What is the difference between rs_free and rs_blks? Shouldn't these
> | two
> | always be identical, since there is no point in reserving blocks
> | which
> | are not free.
> 
> I guess I used a misleading variable name. The two variables have
> two meanings and both are needed. I renamed variable rs_blks to rs_len
> because it represents the length of the reservation.
> 
Thats not really answering the question though... all the blocks in the
reservation must be free, otherwise there is no point in reserving them.
So rs_free should be identical to rs_len or whatever it is called.
Either that or maybe I'm not understanding why there are two different
variables?

[snip]
> | 
> | I'm not sure that I understand this comment at all. Currently with
> | directories we never deallocate any blocks at all until the directory
> | is
> | deallocated when it is unlinked. We will want to extend this to
> | directories eventually, even if we don't do that immediately.
> 
> I clarified the comment to make it more clear what's going on.
> I'm talking about gaps in the _reservation_ not gaps in the blocks.
> The current algorithm makes assumptions based on the fact that block
> reservations don't have gaps, and the "next" free block will be the
> successor to the last claimed. If you use reservations for directories,
> what can happen is that two files may be created, which claims two
> blocks in the reservation. If the first file is deleted from the
> directory, that block becomes a "hole" in the reservation, which breaks
> the code with its current assumptions. We either have to:
> (a) keep the current assumptions which make block claims faster, or
> (b) Make no such assumptions and implement a bitmap-like search of the
>     reservation that can fill holes. It wouldn't be too tough to do,
>     especially since we already have nicely tuned functions to do it.
>     I'm just worried that it's going to hurt performance.
>  
That is just a bug in the way we are doing the allocations. The
allocation of new inodes should be done based on the inode's own
reservation, and not on the reservation of its parent directory. That is
something else on the "to fix" list, but it is complicated to do,

Steve.