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, 19 Dec 2008 10:47:22 +0900
From:	Ian Kent <raven@...maw.net>
To:	Miklos Szeredi <miklos@...redi.hu>
Cc:	linux-fsdevel@...r.kernel.org, jblunck@...e.de,
	dlezcano@...ibm.com, linux-kernel@...r.kernel.org,
	bharata@...ux.vnet.ibm.com, viro@...IV.linux.org.uk,
	Valerie Aurora Henson <vaurora@...hat.com>
Subject: Re: [rfc git patch] union directory

On Thu, 2008-12-18 at 17:45 +0100, Miklos Szeredi wrote:
> On Wed, 17 Dec 2008, Ian Kent wrote:
> > On Fri, 28 Nov 2008, Miklos Szeredi wrote:
> > 
> > > I've been doing some small fixing/cleanup work on the union directory
> > > patches by Jan, and just noticed there's a thread about the union
> > > mounts on LKML, so I thought publicizing won't hurt.
> > > 
> > > It's still a work in progress, notably the readdir code currently only
> > > works on a few specific filesystem types.
> > > 
> > > Git tree is here:
> > > 
> > >   git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/vfs.git union-dir
> > 
> > I'm confused?
> > 
> > This doesn't look like the complete set of Jan Blunks union mount
> > patches.  Am I mistaken?
> 
> You're not mistaken, this is not the original patch set, but a reduced
> one (also by Jan), further reduced and cleaned up by me.

OK, I'll have a closer look, sorry for side tracking the thread (even
though I'm going to continue to do so, hehe).

> 
> The original patch set implemented deep unioning of directory trees.
> This one implements only unioning of the mount's top level directory.
> 
> > But this also made me think about the issues surrounding whiteout support 
> > as having to add per-file system support for such things is bound to lead 
> > to a maintenance headache. So why not a well defined modular interface 
> > layer that includes these bits and is also responsible for context 
> > persistence, independent of file system?
> 
> I don't think such a layer is in the scope of this patch set.  It may
> be a nice thing, but it will almost certainly be implemented in a
> filesystem, not in the VFS.  Union mounts, as opposed to unionfs and
> its ilk, are supposed to be very lightweight.

Exactly, and that is partly my point.

Whether the VFS is implementing readdir for a mount's top level or also
for deeper levels it still has the issue described by Barata Rao in
http://marc.info/?l=linux-fsdevel&m=118914402631822&w=2. But my
suggestion doesn't only relate to the readdir issue it implies managing
such things as whiteout persistence also, but outside of individual file
systems. So, yes, I'm a bit off topic but the patch series here is going
to need something like this somewhere to ultimately be useful and all
I'm saying is that somewhere probably shouldn't be within individual
file systems and, yes, not in the VFS.

Valerie Henson is planning to start a project (when she is done with
current commitments) along the lines of a lightweight stacking layer
with union support included in the file system. These continuing
individual efforts are a little disjoint so such a project could be an
ideal way to define what's needed, what the issues are and how it will
be done in one place. Hopefully everyone that is keen to see progress in
this area will want to be involved too, ;)

Sorry for the off-topic rant, I just can't resist sometimes.

Ian

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

Powered by Openwall GNU/*/Linux Powered by OpenVZ