lkml.org 
[lkml]   [2011]   [Jul]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
From
SubjectRe: [PATCH 0/7] overlay filesystem: request for inclusion
Date
Miklos Szeredi <miklos@szeredi.hu> writes:

> "J. R. Okajima" <hooanon05@yahoo.co.jp> 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@suse.cz>

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@yahoo.co.jp>
Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
---
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.

\
 
 \ /
  Last update: 2011-07-08 16:45    [W:0.142 / U:5.172 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site