Re: [PATCH 19/38] union-mount: Introduce union_dir structure and basic operations

[Miklos Szeredi <miklos@szeredi.hu>]

On Wed, 4 Aug 2010, Valerie Aurora wrote:
> > Why was the hash table concept dropped?  The header comment still
> > talks about that?
> 
> Simply, Al Viro didn't like it.  But note that the current
> implementation still uses part of the hash table solution.  You still
> have union_dir structures external to dentries for the read-only
> layers of the stack.  The change is from Al's observation that the
> topmost dentry could only be part of one stack.  Why do a lookup on
> the topmost dentry when you could keep an pointer to the stack in the
> dentry itself and skip the lookup?  Once you have the head of the
> stack, you don't need lookup for the rest of it.  This eliminates all
> the lookup machinery and the union hash table lock, which seems like a
> big win to me.

That dentry field will be unused most of the time and we lose space
for d_iname for *all* filesystems.  On 64bit this results in max
inline name going from 32 down to 24 bytes.  On my root fs 7% of names
are 24-31 in length.  That's more than triple that of names which are
more than 32 in length.

Yeah, union mounts can be configured out, but that's not much
consolation for distros which want to enable this feature.

> The biggest drawback of the hash table in my mind was that it
> introduced a new global synchronization point in lookup.  Making it go
> fast would be dcache lookup optimization all over again.

I already asked this, but I'll ask again, what about doing this with a
union filesystem?  That solves this problem in one simple go, as well
as a host of others.

I'll do some experimenting because I feel it should be possible to do
all this in a union fs with most of the advantages of union mounts.
That doesn't mean it won't need any VFS support, but I think the
amount of VFS burden can be considerably reduced with that approach at
a small price (just dentry tree duplication).

Miklos