linux-kernel - Re: [UNIONFS] 00/29 Unionfs and related patches pre-merge review (v2)

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]

Message-ID: <20080116212139.GA17255@localhost.austin.ibm.com>
Date:	Wed, 16 Jan 2008 15:21:40 -0600
From:	Michael Halcrow <mhalcrow@...ibm.com>
To:	Erez Zadok <ezk@...sunysb.edu>
Cc:	Christoph Hellwig <hch@...radead.org>,
	torvalds@...ux-foundation.org, akpm@...ux-foundation.org,
	viro@....linux.org.uk, linux-kernel@...r.kernel.org,
	linux-fsdevel@...r.kernel.org
Subject: Re: [UNIONFS] 00/29 Unionfs and related patches pre-merge review (v2)

On Thu, Jan 10, 2008 at 10:57:46AM -0500, Erez Zadok wrote:
> In message <20080110150808.GA32080@...radead.org>, Christoph Hellwig
> writes:
> > On Thu, Jan 10, 2008 at 09:59:19AM -0500, Erez Zadok wrote:
> > > 
> > > Dear Linus, Al, Christoph, and Andrew,
> > > 
> > > As per your request, I'm posting for review the unionfs code
> > > (and related code) that's in my korg tree against mainline
> > > (v2.6.24-rc7-71-gfd0b45d).  This is in preparation for merge in
> > > 2.6.25.
> > 
> > Huh?  There's still aboslutely not fix to the underlying problems
> > of the whole idea.  I think we made it pretty clear that unionfs
> > is not the way to go, and that we'll get the union mount patches
> > clear once the per-mountpoint r/o and unprivilegued mount patches
> > series are in and stable.
> 
> I'll reiterate what I've said before: unionfs is used today by many
> users, it works, and is stable.  After years of working with
> unionfs, we've settled on a set of features that users actually use.
> This functionality can be in mainline today.

There are well-known distributions out there that are tacking Unionfs
onto their kernels; for instance, it is popular in the bootable
read-only media scene. When enough vendors are adding the code on
their own, it is generally a good indicator that it should just be
upstream, especially if it can be built as a non-invasive experimental
module with a caveat about its shortcomings in the config menu and
documentation.

> Unioning at the VFS level, will take a long time to reach the same level of
> maturity and support the same set of features.  Based on my years of
> practical experience with it, unioning directories seems like a simple idea,
> but in practice it's quite hard no matter the approach taken to implement
> it.
> 
> Existing users of unioning aren't likely to switch to Union Mounts
> unless it supports the same set of features.  How long will it
> realistically take to get whiteout support in every lower file
> system that's used by Unionfs users?

Well, depending on the amount of code that actually needs to get
pushed below the VFS layer itself, I think you would be surprised how
quickly something like this can be done. But I do agree that a
non-invasive stacked module is a reasonable intermediate step in the
meantime, so long as the users understand the potential shortcomings
and are able to substantially benefit from its present inclusion in
mainline.

> How will Union Mounts support persistent inode numbers at the VFS
> level?  Those are just a few of the questions.
> 
> I think a better approach would be to start with Unionfs (a
> standalone file system that doesn't touch the rest of the kernel).
> And as Linux gradually starts supporting more and more features that
> help unioning/stacking in general, to change Unionfs to use those
> features (e.g., native whiteout support).  Eventually there could be
> basic unioning support at the VFS level, and concurrently a
> file-system which offers the extra features (e.g., persistency).
> This can be done w/o affecting user-visible APIs.

Would the inclusion of Unionfs in mainline really slow down or damage
the union mount effort? If not, then I think the pragmatic approach
would be to make it available in mainline for all of the users who are
already successfully running it today. We can then focus future
efforts on the VFS-level modifications that address the remaining
issues, limiting Unionfs in the future to only those problems that are
best solved in a stacked filesystem layer.

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