Message-ID: <20130319212401.GJ21522@ZenIV.linux.org.uk>
Date:	Tue, 19 Mar 2013 21:24:01 +0000
From:	Al Viro <viro@...IV.linux.org.uk>
To:	Miklos Szeredi <miklos@...redi.hu>
Cc:	Jan Kara <jack@...e.cz>, David Howells <dhowells@...hat.com>,
	torvalds@...ux-foundation.org, linux-fsdevel@...r.kernel.org,
	linux-kernel@...r.kernel.org, hch@...radead.org,
	akpm@...ux-foundation.org, apw@...onical.com, nbd@...nwrt.org,
	neilb@...e.de, jordipujolp@...il.com, ezk@....cs.sunysb.edu,
	sedat.dilek@...glemail.com, hooanon05@...oo.co.jp, mszeredi@...e.cz
Subject: Re: [PATCH 2/9] vfs: export do_splice_direct() to modules

On Tue, Mar 19, 2013 at 07:32:42PM +0100, Miklos Szeredi wrote:

> >         * victim is negative => create a whiteout
> >         * victim is a directory, parent opaque => rmdir
> >         * victim is a non-directory, parent opaque => unlink
> >         * victim is positive, parent _not_ opaque => replace with whiteout
> >         * old_dir in case of ->rename() is opaque => normal rename
> >         * old_dir in case of ->rename() is not opaque => leave whiteout behind
> > Non-unioned => opaque, of course (nothing showing through it).
> >
> 
> I dunnow.  Overloading common paths with overlay/union specific things
> doesn't look very clean to me.

We certainly can add a couple of new methods; the question is, would that
buy us anything?  This ->rename_and_whiteout would be practically identical
to ->rename on most of filesystems; the only difference for something like
ext* is that instead of deleting the old directory entry in the end we
would change its inumber to 0 and type to 14.  Everything else would be
the same.  Moreover, turning a positive entry into a whiteout differs from
unlink/rmdir resp. in exactly the same way.  FWIW, creating a whiteout from
scratch might be better off as a separate method - it's closer to ->mknod()
and friends.  But whiteout from positive and whiteout-on-rename probably
isn't worth separating from the normal methods.  All we end up "overloading"
is actual removal of directory entry, which is a rather minor part of the
logics in those.

And merging ->unlink/->rmdir is definitely a good idea, regardless of anything
union-related; just look at the existing instances of both.

> > Getting good behaviour on rename interrupted by crash is going to be _very_
> > tricky with any strategy other than whiteouts-in-fs, AFAICS.
> >
> 
> One idea is to add a journal to the overlay itself (yeah, namespace issues).

... and extra complexity from hell.  If the underlying fs has a journal of
its own, we are getting all kinds of interesting interplay between those;
if not, replaying the journal in overlay will buy you nothing, since the
damage to underlying objects makes it all moot.

Layering is a very nice tool for quick prototyping; no arguments about that.
It allows to avoid modifying $BIGNUM filesystems and for something that
lives out of tree it's a very big benefit.  Once the thing is merged, though,
that benefit becomes much smaller; it still might make sense to implement
something as a layer, but some parts of that sucker may be better off as
fs primitives.  Hell, we could, in theory, implement xattrs as a layer;
just look at how reiserfs had done them.  We could do the same for hardlinks
(look at qnx4, if you wish to see that hack).  Of for symlinks (sysvfs).
Or for opened-and-unlinked files (sillyrename could be done as a generic
layer).  Or for permissions/ownership/arbitrary names (umsdos, and that
_was_ very similar to layering).  It's just that often an underlying fs
has a better way of doing that.  IMO whiteouts are in that class.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists