linux-kernel - Re: [PATCH 19/38] union-mount: Introduce union

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 6 Aug 2010 13:09:08 -0400
From:	Valerie Aurora <vaurora@...hat.com>
To:	Miklos Szeredi <miklos@...redi.hu>
Cc:	viro@...iv.linux.org.uk, jblunck@...e.de, hch@...radead.org,
	linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org
Subject: Re: [PATCH 19/38] union-mount: Introduce union_dir structure and basic operations

On Thu, Aug 05, 2010 at 12:28:18PM +0200, Miklos Szeredi wrote:
> 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.

I'll bring it up with Al.

> > 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).

That would be great.  My theory on the current version is to do
everything in the VFS except when it is much cleaner to make minor
changes to the underlying fs.  I went this way because I'd worked on a
stacked file system version and couldn't see how to avoid the
complexity that unionfs ran into.  But a VFS/stacked fs hybrid might
look nicer than a VFS/low-level fs hybrid.

-VAL
--
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/