From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tomas M Subject: Re: [PATCH 0/7] overlay filesystem: request for inclusion Date: Fri, 8 Jul 2011 17:21:20 +0200 Message-ID: References: <1306932380-10280-1-git-send-email-miklos@szeredi.hu> <20110608153208.dc705cda.akpm@linux-foundation.org> <20110609115934.3c53f78f@notabene.brown> <20110608205233.ebfedc4d.akpm@linux-foundation.org> <87wrgvb28a.fsf@tucsk.pomaz.szeredi.hu> <20110609123843.77153b27.akpm@linux-foundation.org> <877h8uzmsi.fsf@tucsk.pomaz.szeredi.hu> <21324.1307677721@jrobl> <871uyxa7ol.fsf@tucsk.pomaz.szeredi.hu> <8739ig3k93.fsf@tucsk.pomaz.szeredi.hu> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: "J. R. Okajima" , Andrew Morton , NeilBrown , viro@zeniv.linux.org.uk, torvalds@linux-foundation.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, apw@canonical.com, nbd@openwrt.org, hramrach@centrum.cz, jordipujolp@gmail.com, ezk@fsl.cs.sunysb.edu To: Miklos Szeredi Return-path: In-Reply-To: <8739ig3k93.fsf@tucsk.pomaz.szeredi.hu> Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org > Here's a patch to document these limitations. Why would we need to 'document limitations' if we can use code which DOESN'T IMPOSE the limitations? (read: aufs) Believe me or not, OverlayFS will be pointless if there are any limitations which make the final 'filesystem' work inconsistently from the behavior expected by crazy applications, like KDE suite, for example. Inode number change (as mentioned in the 'non-standard' behavior documentation) is a NO NO option, really, applications rely on that more than you would expect! Tomas M On Fri, Jul 8, 2011 at 4:44 PM, Miklos Szeredi wrot= e: > Miklos Szeredi writes: > >> "J. R. Okajima" 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 UnionMoun= t. >>> >>> 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 s= ome >>> 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) aft= er >>> =A0 open(O_RDWR). > > Here's a patch to document these limitations. > > Thanks, > Miklos > ---- > > Subject: ovl: add limitation to documentation > > From: Miklos Szeredi > > J. R. Okajima noted some examples where overlayfs behaves differently > from a standard filesystem. =A0Describe these cases in the documentat= ion. > > Reported-by: "J. R. Okajima" > Signed-off-by: Miklos Szeredi > --- > =A0Documentation/filesystems/overlayfs.txt | =A0 29 +++++++++++++++++= ++++++++++-- > =A01 file changed, 27 insertions(+), 2 deletions(-) > > Index: linux-2.6/Documentation/filesystems/overlayfs.txt > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- linux-2.6.orig/Documentation/filesystems/overlayfs.txt =A0 =A0 =A0= 2011-07-07 16:01:47.000000000 +0200 > +++ linux-2.6/Documentation/filesystems/overlayfs.txt =A0 2011-07-08 = 14:16:44.000000000 +0200 > @@ -143,6 +143,9 @@ to the upper filesystem (copy_up). =A0Note > =A0also requires copy_up, though of course creation of a symlink does > =A0not. > > +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. > + > =A0The copy_up process first makes sure that the containing directory > =A0exists in the upper filesystem - creating it and any parents as > =A0necessary. =A0It then creates the object with the same metadata (o= wner, > @@ -156,6 +159,27 @@ filesystem - future operations on the fi > =A0overlay filesystem (though an operation on the name of the file su= ch as > =A0rename 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. =A0The 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. =A0Similarly any file locks obtained before copy_up will n= ot > +apply to the copied up file. > + > +If a file with multiple hard links is copied up, then this will > +"break" the link. =A0Changes 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-directo= ry > +object in overlayfs will not contain vaid absolute paths, only > +relative paths leading up to the filesystem's root. =A0This will be > +fixed in the future. > + > =A0Changes to underlying filesystems > =A0--------------------------------- > > @@ -163,5 +187,6 @@ Offline changes, when the overlay is not > =A0the upper or the lower trees. > > =A0Changes to the underlying filesystems while part of a mounted over= lay > -filesystem are not allowed. =A0This is not yet enforced, but will be= in > -the future. > +filesystem are not allowed. =A0If the underlying filesystem is chang= ed, > +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-fsdev= el" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at =A0http://vger.kernel.org/majordomo-info.html >