From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steven Whitehouse Date: Fri, 18 Nov 2011 14:38:04 +0000 Subject: [Cluster-devel] [GFS2 PATCH] GFS2: decouple quota allocations from block allocations In-Reply-To: <42da4896-78f6-47f1-9525-df6ba9880090@zmail16.collab.prod.int.phx2.redhat.com> References: <42da4896-78f6-47f1-9525-df6ba9880090@zmail16.collab.prod.int.phx2.redhat.com> Message-ID: <1321627084.2729.37.camel@menhir> List-Id: To: cluster-devel.redhat.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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.