linux-kernel - Re: [PATCH 0/7] overlay filesystem: request for inclusion

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 for Android: free password hash cracker in your pocket

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

Message-Id: <B723B526-D658-4D22-A9CE-598444148B07@fsl.cs.sunysb.edu>
Date:	Wed, 15 Jun 2011 17:44:33 -0700
From:	Erez Zadok <ezk@....cs.sunysb.edu>
To:	Miklos Szeredi <miklos@...redi.hu>
Cc:	"J. R. Okajima" <hooanon05@...oo.co.jp>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Valerie Aurora <val@...consulting.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	NeilBrown <neilb@...e.de>,
	"viro@...IV.linux.org.uk" <viro@...IV.linux.org.uk>,
	"torvalds@...ux-foundation.org" <torvalds@...ux-foundation.org>,
	"linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"apw@...onical.com" <apw@...onical.com>,
	"nbd@...nwrt.org" <nbd@...nwrt.org>,
	"hramrach@...trum.cz" <hramrach@...trum.cz>,
	"jordipujolp@...il.com" <jordipujolp@...il.com>
Subject: Re: [PATCH 0/7] overlay filesystem: request for inclusion

On Jun 15, 2011, at 8:49 AM, Miklos Szeredi wrote:

> It's not to make sure that modifications of underlying filesystems will
> have sane semantics.

Miklos, I agree with you. I think it makes perfect sense for overlayfs at this point not to bother with users who modify lower files directly, and expect sane semantics at the upper layer.  Most unioning users do NOT do that anyway, but the few who do cause unioning code to be much more complex.

That said, if users do go and add/del files below overlayfs, it shouldn't oops...

I've often been bothered by people who suggested that stackable file systems must solve the "cache coherency" problem and must perfectly detect lower-level changes consistently.  A lot of code in Unionfs is spent on cache coherency.

Ecryptfs has been around for several years, and I've yet to see the masses scream for upper/lower layer consistency.  NFS works just fine for years and no one expects changes to server-side disk-based file system to be reflected immediately and correctly on al clients.  Asking overlayfs or other stackable file systems to solve this multi-layer coherency perfectly is somewhat ridiculous: we don't expect file systems like ext3 to detect and correctly handle changes to lower devices — i.e., if someone hand-edited direct blocks in /dev/sda1, do we?

The union mount team also tried to handle this issue (the so-called "really really NFS readonly" idea).  And it's really hard — and unnecessary for v1 of a unioning solution.

Skip this can of worms, Miklos.  And you'll be happier for it. :-)  I think your approach of keeping Overlayfs small for now is absolutely the right way.

Cheers,
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/