linux-kernel - Re: [PATCH 5/9] overlay filesystem

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:	Wed, 13 Mar 2013 15:53:21 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Miklos Szeredi <miklos@...redi.hu>
Cc:	viro@...IV.linux.org.uk, torvalds@...ux-foundation.org,
	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
	hch@...radead.org, apw@...onical.com, nbd@...nwrt.org,
	neilb@...e.de, jordipujolp@...il.com, ezk@....cs.sunysb.edu,
	dhowells@...hat.com, sedat.dilek@...glemail.com,
	hooanon05@...oo.co.jp, mszeredi@...e.cz
Subject: Re: [PATCH 5/9] overlay filesystem

On Wed, 13 Mar 2013 15:16:29 +0100 Miklos Szeredi <miklos@...redi.hu> wrote:

> Overlayfs allows one, usually read-write, directory tree to be
> overlaid onto another, read-only directory tree.  All modifications
> go to the upper, writable layer.
> 
> This type of mechanism is most often used for live CDs but there's a
> wide variety of other uses.
> 
> The implementation differs from other "union filesystem"
> implementations in that after a file is opened all operations go
> directly to the underlying, lower or upper, filesystems.  This
> simplifies the implementation and allows native performance in these
> cases.

Well that's an implementation detail.  I'm sure that people would like
to see a longer description of how this fs differs from others and the
pros and cons of the various approaches.

Is overlayfs equal or superior to all other union filesystems in all
respects?  If not, what are its shortcomings and why do you expect that
users will find them tolerable?

> The dentry tree is duplicated from the underlying filesystems, this
> enables fast cached lookups without adding special support into the
> VFS.  This uses slightly more memory than union mounts, but dentries
> are relatively small.
> 
> Currently inodes are duplicated as well, but it is a possible
> optimization to share inodes for non-directories.
> 
> Opening non directories results in the open forwarded to the
> underlying filesystem.  This makes the behavior very similar to union
> mounts (with the same limitations vs. fchmod/fchown on O_RDONLY file
> descriptors).
> 
> Usage:
> 
>   mount -t overlay -olowerdir=/lower,upperdir=/upper overlay /mnt
> 
> Supported:
> 
>  - all operations
> 
> Missing:
> 
>  - Currently a crash in the middle of copy-up, rename, unlink, rmdir or create
>    over a whiteout may result in filesystem corruption on the overlay level.
>    IOW these operations need to become atomic or at least the corruption needs
>    to be detected.

I for one have forgotten what "whiteout" means in this context. 
Perhaps a lengthier description of this fs would be helpful...
--
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/