[Cluster-devel] [GFS2 PATCH] GFS2: decouple quota allocations from block allocations

[Steven Whitehouse <swhiteho@redhat.com>]

Hi,

On Fri, 2011-11-18 at 08:56 -0500, Bob Peterson wrote:
> ----- Original Message -----
> | Hi,
> | 
> | On Thu, 2011-11-17 at 15:29 -0500, Bob Peterson wrote:
> | > Hi,
> | > 
> | > As hinted at in my previous post:
> | > This patch separates the code pertaining to allocations into two
> | > parts: quota-related information and block reservations. This is
> | > another step toward making multi-block reservations in order to
> | > reduce GFS2 file fragmentation.
> | > 
> | > Regards,
> | > 
> | > Bob Peterson
> | > Red Hat File Systems
> | 
> | Can you explain the intended lifetimes of the structures? I'm not
> | sure I
> | see the advantage of splitting them in this way. All of the current
> | fields are only required during the time that an allocation is taking
> | place, unless perhaps you are intending to use the holder for the
> | rgrp
> | to keep a ref to the rgrp for longer periods of time.
> | 
> | In that case, it would be a good plan to merge that holder into the
> | inode, since we already have i_rgd whose function could be shared
> | with
> | it.
> | 
> | Also, al_requested looks like it should be a parameter to
> | gfs2_inplace_reserve and not part of the data structure anyway. So
> | that
> | can just be removed I suspect,
> | 
> | Steve.
> 
> Hi,
> 
> This patch merely splits the two block allocation types into
> two pieces and doesn't change the lifetime of either (yet).
> The gfs2_qadata (quota allocation) structure will have
> the same lifetime it does today: only the duration of the
> allocation. Eventually I want to change the gfs2_blkreserv
> to have a longer lifetime so that back-to-back writes to the
> same file will use blocks from the previous allocation.
> That work still is in progress and may be a bit tricky.
> 
> My intent is ultimately to simplify things and make them
> easier to do a multi-block reservation system. The next patch
> replaces ALL the calls to gfs2_blkrsv_get and related logic
> with a single call inside function gfs2_inplace_reserve, which
> will take a single parameter for how many blocks to reserve,
> just as you suggested. The function can then be static, within
> rgrp.c. 
> 
Ok, that sounds like a good plan.

> I may also be able to make gfs2_inplace_release release the
> reservation as well, but I haven't done that work yet.
> 
The reservation release needs to be related to whether the file is open
or not (for regular files). I think it is an open question at the moment
as to what makes sense for directories at the moment.

> I'm splitting all these patches up to avoid having one massive
> patch that's impossible to understand and tries to encompass
> the whole problem. So far I'm trying to not change any lifetimes,
> and I'm running basic tests like fs_mark and postmark before
> posting anything. 
> 
> My biggest concern is with the recently added fallocate code
> which is a bit tricky when it comes to allocations, and will
> need special attention and careful reviews.
> 
> Regards,
> 
> Bob Peterson
> Red Hat File Systems

Ok, that makes sense, but I'll hold off on this one until the next patch
is ready too I think. It is likely that the rest of the write code will
start to follow the pattern set by fallocate in the not too distant
future,

Steve.