Re: [-mm patch] UNION_FS must depend on SLAB

[Josef Sipek <jsipek@fsl.cs.sunysb.edu>]

On Wed, Feb 21, 2007 at 06:26:57PM -0800, Andrew Morton wrote:
> On Wed, 21 Feb 2007 21:00:39 -0500 Josef Sipek <jsipek@fsl.cs.sunysb.edu> wrote:
> 
> > > I can't say more until I've managed to understand your description, which
> > > might take a while.
> > 
> > It is intended for reallocation of a buffer. The code in lookup.c allocates
> > some memory, and it may have to reallocate the buffer. The code tries to
> > prevent some unneeded allocations by looking at what the smallest object the
> > slabcache gives you is.
> > 
> > I hope this explains it better. There's some discussion about this in the
> > threads by Pekka Enberg.
> 
> Problem is, it doesn't seem that we'll be merging unionfs any time soon so
> we shouldn't be adding slab infrastructure on its behalf.  And I'd prefer
> not to have to carry slab changes in a filesystem tree.
> 
> Although if the changes are generally ok-looking and are compact then it'd
> be OK, but I do need to be alert for someone who comes along and uses that
> infrastructure in an unrelated patch, which has happened before.  When I
> prep the patch for an upstream merge, oops, doesn't compile any more.
 
Sounds reasonable to be weary of patches like that...
 
> So for now, it'd be best to jsut forget about the optimisation.

Well...

> How useful is it, anyway?

The code in lookup gets called frequently enough that I'm not sure. Whenever
one touches a file on a read-only branch, a copyup is done. This may have to
recreate the directory hierarchy leading up to the file - since the VFS
doesn't have such code, unionfs builds up a stack of all the path
components, and then it pops them off one at a time calling vfs_mkdir for
each. The stack creation is where we do this "reallocation."

Josef "Jeff" Sipek.

-- 
I'm somewhere between geek and normal.
		- Linus Torvalds