[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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

----- 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.


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

I may also be able to make gfs2_inplace_release release the
reservation as well, but I haven't done that work yet.

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.


Bob Peterson
Red Hat File Systems

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]