[Top] [All Lists]

Re: [PATCH 04/11] xfs: factor out xfs_da_grow_inode_int

To: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Subject: Re: [PATCH 04/11] xfs: factor out xfs_da_grow_inode_int
From: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Tue, 12 Jul 2011 10:55:35 +1000
Cc: xfs@xxxxxxxxxxx
In-reply-to: <20110711052406.GA13266@xxxxxxxxxxxxx>
References: <20110710204916.856267100@xxxxxxxxxxxxxxxxxxxxxx> <20110710205017.485558926@xxxxxxxxxxxxxxxxxxxxxx> <20110711003743.GC23038@dastard> <20110711052406.GA13266@xxxxxxxxxxxxx>
User-agent: Mutt/1.5.20 (2009-06-14)
On Mon, Jul 11, 2011 at 01:24:06AM -0400, Christoph Hellwig wrote:
> On Mon, Jul 11, 2011 at 10:37:43AM +1000, Dave Chinner wrote:
> > On Sun, Jul 10, 2011 at 04:49:20PM -0400, Christoph Hellwig wrote:
> > > xfs_da_grow_inode and xfs_dir2_grow_inode are mostly duplicate code.  
> > > Factor
> > > the meat of those two functions into a new common helper.
> > 
> > Hmmmm. I'm in the process of splitting xfs_dir2_grow_inode() into
> > data space vs free space variants so I can play speculative
> > preallocation tricks in the directory data space to reduce dataspace
> > fragmentation for large directories. Combined with a rework of the
> > readir readahead code, it significantly reduces IO count and seeks
> > for readdir calls...
> > 
> > I'll probably just rebase on top of this patch, though, because I did
> > notice that the two functions were very similar to begin with. ;)
> Are you two variants still sharing the core code?

Sort of - there's an extra allocation failure case added (multiple
directory block size allocation failure), but otherwise is the same.

> If yes rebasing sounds
> like the better idea.  If the two dir2 variants are different enough
> from the da variant I'm fine with postponing this one for now.

I'll rebase anyway - the code won't be ready for 3.1 because I
haven't yet started on the readahead optimisations that better
allocation allows. I also need to add dataspace truncation during
inactivation so that we don't leave blocks in the data space "beyond
EOF" that repair complains about on clean unmounts.

And FWIW, I think I now know enough about how this all works to be
able to implement online directory data space defragmentation now...


Dave Chinner

<Prev in Thread] Current Thread [Next in Thread>