On Wed, Apr 19, 2017 at 12:16 PM, Miklos Szeredi <miklos@xxxxxxxxxx> wrote: > On Tue, Apr 18, 2017 at 8:37 PM, Amir Goldstein <amir73il@xxxxxxxxx> wrote: >> >> On Mon, Apr 17, 2017 at 2:59 AM, Amir Goldstein <amir73il@xxxxxxxxx> wrote: >> > Overlayfs inodes are considered unstable in several aspects, >> > because on a copy up event: >> > 1. st_ino can change >> > 2. st_dev can change >> > 3. hardlinks are broken >> > 4. NFS handle would become stale >> > 5. content of read-only file descriptor would become stale >> > >> > This patch set 'stabilizes' overlayfs inodes w.r.t. st_ino/st_dev >> > and takes some big steps in the direction of stabilizing hardlinks >> > and NFS handles. >> > >> >> I realized I forgot to mention in the cover letter that stable inodes >> are only available for the overlay configuration where all layers >> are on the same underlying fs and that underlying fs support >> NFS export (I think all eligible upper fs support NFS export anyway). > > Hmm, we could keep inode numbers stable across copy up even if layers > are on different filesystems: just need to use a separate st_dev for > lower layers and keep st_dev and st_inode constant. The only extra > thing needed compared to the samefs case is the allocation of dummy > device numbers for lower layers. Of course "find -xdev" and the like > still won't work properly, and we wouldn't be able to provide sane > d_ino values in readdir. Not sure that is going to be worth the effort, but we'll see. Anyway, not sure if you already read far enough into the series, but the fact that overlay inodes are hashed by stable inode ino helps solving a lot of the problems with minimal code changes, so in the grand scheme of things, I think it would be easier to say: same_fs can give you POSIX. non same_fs cannot. > But NFS export should actually work, since > we can encode the device number in the file handle. That's true. But it comes down to the question of are there any users for this. I mean if we provide full POSIX and NFS export to same_fs case, would it be interesting to provide NFS export and partial constant inode numbers (not for d_ino) for non same_fs case? > > Lets keep things simple for now, so those are just things to keep in > mind but the actual implementation can wait. > > Thanks, > Miklos -- To unsubscribe from this list: send the line "unsubscribe linux-unionfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
