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

[Miklos Szeredi]

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-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/