Re: Fallthrus as full-length symlinks?

[Valerie Aurora <vaurora@redhat.com>]

On Mon, Nov 23, 2009 at 07:44:19PM +0100, Arnd Bergmann wrote:
> On Monday 23 November 2009, Valerie Aurora wrote:
> > > BTW, we might try to figure out a way to use these symlinks to optimize any
> > > copyup that's not strictly necessary.  A rename() doesn't change the file's
> > > data, hence this symlink idea is suitable.  But also, there are other
> > > meta-data changes to a file which don't affect its data (chmod, chown,
> > > chgrp, etc.), for which a symlink would be suitable.  This would require
> > > that we could easily change the meta-data of the symlink itself, and return
> > > that metadata in the upper inode, while using the lower file's data for
> > > read().
> > 
> > I like this idea.  Copying up the file's data in chown(), etc. is an
> > enormous pain and hard to work into the existing code path.  It might
> > be possible to do with this with the directory entry-based approach as
> > well.
> 
> I guess we can even support strict atime updates with that, which would be
> even more painful to do with copyup because they happen more frequently
> than other inode changes. AFAIK the consensus for other union
> mount implementations was always that strictatime cannot be sanely
> done, or not done persistantly.

Okay, this seems really worthwhile to try then.

It seems like we can, as before, create a per-fs DT_FALLTHRU file type
(since we're out of bits for the VFS-level file type).  Then, instead
of reusing the file systems' "normal" directory entry code, we reuse
the symlink code.  As an example, with the current code,
ext2_fallthru_dentry() is a lot of copy-n-paste from ext2_add_link();
in the new version it would look a lot like or call ext2_symlink().

-VAL