Miklos Szeredi <miklos@xxxxxxxxxx> writes: > "J. R. Okajima" <hooanon05@xxxxxxxxxxx> writes: >> If I remember correctly, Miklos has mentioned about it like this. >> - overlayfs provides the same feature set as UnionMount. >> - but its implementation is much smaller and simpler than UnionMount. >> >> I agree with this argument (Oh, I have to confess that I don't test >> overlayfs by myself). But it means that overlayfs doesn't provide some >> features which UnionMount doesn't provide. I have posted about such >> features before, but I list them up again here. >> - the inode number may change silently. >> - hardlinks may corrupt by copy-up. >> - read(2) may get obsolete filedata (fstat(2) for metadata too). >> - fcntl(F_SETLK) may be broken by copy-up. >> - unnecessary copy-up may happen, for example mmap(MAP_PRIVATE) after >> open(O_RDWR). Here's a patch to document these limitations. Thanks, Miklos ---- Subject: ovl: add limitation to documentation From: Miklos Szeredi <mszeredi@xxxxxxx> J. R. Okajima noted some examples where overlayfs behaves differently from a standard filesystem. Describe these cases in the documentation. Reported-by: "J. R. Okajima" <hooanon05@xxxxxxxxxxx> Signed-off-by: Miklos Szeredi <mszeredi@xxxxxxx> --- Documentation/filesystems/overlayfs.txt | 29 +++++++++++++++++++++++++++-- 1 file changed, 27 insertions(+), 2 deletions(-) Index: linux-2.6/Documentation/filesystems/overlayfs.txt =================================================================== --- linux-2.6.orig/Documentation/filesystems/overlayfs.txt 2011-07-07 16:01:47.000000000 +0200 +++ linux-2.6/Documentation/filesystems/overlayfs.txt 2011-07-08 14:16:44.000000000 +0200 @@ -143,6 +143,9 @@ to the upper filesystem (copy_up). Note also requires copy_up, though of course creation of a symlink does not. +The copy_up may turn out to be unnecessary, for example if the file is +opened for read-write but the data is not modified. + The copy_up process first makes sure that the containing directory exists in the upper filesystem - creating it and any parents as necessary. It then creates the object with the same metadata (owner, @@ -156,6 +159,27 @@ filesystem - future operations on the fi overlay filesystem (though an operation on the name of the file such as rename or unlink will of course be noticed and handled). + +Non-standard behavior at copy_up +-------------------------------- + +The copy_up operation essentially creates a new, identical file and +moves it over to the old name. The new file may be on a different +filesystem, so both st_dev and st_ino of the file may change. + +Any open files referring to this inode will access the old data and +metadata. Similarly any file locks obtained before copy_up will not +apply to the copied up file. + +If a file with multiple hard links is copied up, then this will +"break" the link. Changes will not be propagated to other names +referring to the same inode. + +Symlinks in /proc/PID/ and /proc/PID/fd which point to a non-directory +object in overlayfs will not contain vaid absolute paths, only +relative paths leading up to the filesystem's root. This will be +fixed in the future. + Changes to underlying filesystems --------------------------------- @@ -163,5 +187,6 @@ Offline changes, when the overlay is not the upper or the lower trees. Changes to the underlying filesystems while part of a mounted overlay -filesystem are not allowed. This is not yet enforced, but will be in -the future. +filesystem are not allowed. If the underlying filesystem is changed, +the behavior of the overlay is undefined, though it will not result in +a crash or deadlock. -- 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
