linux-kernel - Re: [RFC PATCH 1/4] Union mount documentation.

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:	Thu, 21 Jun 2007 12:39:38 -0400
From:	Erez Zadok <ezk@...sunysb.edu>
To:	Josef Sipek <jsipek@....cs.sunysb.edu>
Cc:	Bharata B Rao <bharata.rao@...il.com>,
	Erez Zadok <ezk@...sunysb.edu>, Jan Blunck <jblunck@...e.de>,
	linux-kernel@...r.kernel.org, bharata@...ux.vnet.ibm.com
Subject: Re: [RFC PATCH 1/4] Union mount documentation. 

In message <20070621162900.GA9457@...er.fsl.cs.sunysb.edu>, Josef Sipek writes:
> On Thu, Jun 21, 2007 at 10:55:45AM +0530, Bharata B Rao wrote:
> ... 
> > Talking about copyup and whiteout at VFS layer, we have already
> > demonstrated what complexity it takes to have these within VFS. Please
> > take a look at the copyup and whiteout patches in our previous
> > releases at:
> > 
> > http://lkml.org/lkml/2007/4/17/150
> > http://lkml.org/lkml/2007/5/14/69
> > 
> > Or may be wait till I clean all those up to work with the new union
> > new stack infrastructure which I have posted here.
> 
> Really, the problem for both, union mounts and unionfs, is that the concept
> of unioning spans the two layers. You have the unification part - which is
> very VFS-level concept, but at the same time, you got whiteouts, copyup,
> (semi-?)persistent inode numbers, and a bunch of other details that just
> don't belong in the VFS at all.
> 
> Josef "Jeff" Sipek.

Yup, which is why I feel that the eventual solution may involve a hybrid
solution: a file system "driver" plus ample VFS support.  The question will
always be how much should go into the VFS and how much should go into the
f/s driver?  Our approach w/ unionfs had been to keep as much of it into the
f/s driver, and slowly offer VFS-level support, so as not to perturb the VFS
too much all at once.  That way we can offer users something that works now,
and internally change the implementation with minimal user-visible changes.

Erez.
-
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/