Re: Unique st_ino/st_dev for non-samefs

[Chandan Rajendra <chandan@linux.vnet.ibm.com>]

On Monday, June 5, 2017 10:05:16 PM IST Amir Goldstein wrote:
> On Mon, Jun 5, 2017 at 6:07 PM, Chandan Rajendra
> <chandan@linux.vnet.ibm.com> wrote:
> >
> > Hi Amir,
> >
> > I realized only now that I misunderstood the problem statement. Now I am
> > confused. Apologies for bringing this up so late.
> >
> > With the code from ovl-constino branch, I see that ovl_getattr() already
> > generates unique and constant (for the duration of fs 'mount' cycle atleast)
> > combinations of (st_ino, st_dev).
> >
> > In the cover letter of the "Constant Inode numbers" patchset, you had
> > mentioned "System-wide unique st_dev;st_ino for non-samefs" as the
> > TODO. From the code in ovl_getattr() I feel that we are already generating
> > filesystem-wide unique combinations of (st_dev, st_ino).
> >
> > I understand that I am missing something here. Could you please point out the
> > case where we don't yet have system-wide unique (st_dev, st_ino) combination?
> >
> 
> Sure. You are missing a subtle detail.
> From Documentation/filesystems/overlayfs.txt:
> 
> "This approach is 'hybrid' because the objects that appear in the
> filesystem do not all appear to belong to that filesystem.  In many
> cases an object accessed in the union will be indistinguishable
> from accessing the corresponding object from the original filesystem.
> This is most obvious from the 'st_dev' field returned by stat(2)."
> 
> And for v4.12, I added this text:
> "In the special case of all overlay layers on the same underlying
> filesystem, all objects will report an st_dev from the overlay
> filesystem and st_ino from the underlying filesystem.  This will
> make the overlay mount more compliant with filesystem scanners and
> overlay objects will be distinguishable from the corresponding
> objects in the original filesystem."
> 
> So the case where we don't yet have system-wide unique (st_dev/st_ino)
> is the file /lower/foo has the same st_dev/st_ino as the file /mnt/foo,
> where /mnt is an overlay of /lower and /upper on not same fs.
> And what is worse, as Miklos pointed out is that after copy up,
> /mnt/foo with still have the same st_dev/st_ino as /lower/foo,
> but now they will have a different data and diff won't know it, because
> it does not bother to compare data when st_dev/st_ino are equal.

Amir, Thanks for the clarification. I was under the assumption that we would
not support the usecase wherein the userspace programs would access files on
overlayfs and files on the lowerdir simultaneously. 

I have coded up the fake st_dev part. The fake st_devs are obtained using 
get_anon_bdev(). I am now working on enhancing the tests.

> 
> The solution is quite simple and therefore the task itself is quite simple,
> mostly the challenge is to write the tests for the use cases.
> 
> All you need to do at  overlay mount time, for non-samefs case, is to
> allocate a fake st_dev value for each layer (or for each unique fs) and
> store those values in the  ovl_fs private struct.
> 
> Then the code in ovl_getattr() will simply set those fake st_dev values
> instead of the rel values, for example:
> 
> @@ -110,6 +110,8 @@ int ovl_getattr(const struct path *path, struct kstat *stat,
>                 }
>                 if (samefs)
>                         stat->dev = dentry->d_sb->s_dev;
> +               else
> +                       stat->dev = ovl_fake_dev(stat->s_dev);
>         } else {
>                 /*
>                  * Always use the overlay st_dev for directories, so 'find
> 
> I am not sure how sdev id's are allocated for anonymous devices
> (like the overlay sdev itself), but it is possible to reserve a namespace for
> overlayfs then maybe the conversion ovl_fake_dev() can be static - I doubt it.
> More likely this would have to be a lookup in the fake id's by real id's map
> that you created at mount time.
> 
> Let me know if you need more clarifications.
> 


-- 
chandan