Re: [PATCH] ovl: System-wide unique st_dev

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Jun 20, 2017 at 12:39 PM, Chandan Rajendra
<chandan@xxxxxxxxxxxxxxxxxx> wrote:
> On Monday, June 19, 2017 11:15:37 PM IST Amir Goldstein wrote:
>> On Mon, Jun 19, 2017 at 6:22 PM, Chandan Rajendra
>> <chandan@xxxxxxxxxxxxxxxxxx> wrote:
>> > On an overlayfs instance having lower and upper dirs on the same
>> > filesystem, stat(2) on a file residing on the lower dir will
>>
>> This is not what the patch should do. The patch should deal with !samefs case.
>>
>> > provide st_dev corresponding to the lower filesystem's bdev. Later, After
>> > the lower file is copied-up, stat(2) on the file provides st_dev
>> > corresponding to the overlayfs' pseudo device. Hence we have a mismatch
>> > in the st_dev value that is provided to the userspace.
>>
>> All this is true, but you patch should not be bothering with constant st_dev
>> over copy up. my patches do that.
>> Your patch should provide the pseudo st_dev for lower, which my patch
>> "relax same fs constrain for constant st_ino" needs to be able to use
>> the lower (pseudo) dev as the constant st_dev across copy up.
>
> Ok. But we continue to use overlayfs' anon dev when reporting st_dev for
> directories right?
>

Right... which means I was wrong about reporting the overlay st_dev for
upper non-dir, because this could create st_dev/st_ino collision.
Dir st_ino come from the overlay inode number pool and non-dir st_ino
come from underlying fs.

Easiest is to just return the real st_dev for pure upper, i.e.:

+       if (ofs->upper_mnt && ofs->upper_mnt->mnt_sb->s_dev == dev)
+               return dev;
+

I am not sure that the benefits of allocating a pseudo dev also for upper
layer are worth it. At the end of the day, a pure upper overlay object is
really the same object as the underlying fs object and reporting a
pseudo dev for those objects isn't going to help with du -x, so why bother.

Amir.
--
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



[Index of Archives]     [Linux Filesystems Devel]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux