On Wed, 13 Mar 2013 15:16:29 +0100 Miklos Szeredi <miklos@xxxxxxxxxx> 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-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
