Re: [PATCH v4 00/15] overlayfs constant inode numbers

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

 



On Wed, May 10, 2017 at 12:21 PM, Miklos Szeredi <miklos@xxxxxxxxxx> wrote:
> On Wed, May 10, 2017 at 10:58 AM, Amir Goldstein <amir73il@xxxxxxxxx> wrote:
>>
>> Is it too soon to nudge you about the pull request? ;-)
>
> I'll have a look.
>
> My plan is to send a pull request to Linus for the const ino stuff,
> and then leave the rest to 4.13.
>

Sure, no rush about verify_lower, I just meant to nudge about the pull
request for const ino.

> This is the list I have in my head for what's missing:
>
> - lookup origin dir for snapshots
> - const ino for non-samefs
> - correct d_ino for copied up entries
> - NFS export support
> - hardlink unbreaking
> - sharing pages for reflink (*)
> - ro/rw correctness for samefs with temp reflink (**)
> - sharing pages in the general case (*)
>

Just updated TODO with the a similar list yesterday ;)
https://github.com/amir73il/overlayfs/wiki/Overlayfs-TODO

> (*) very preliminary design
> (**) need to check overhead: I have a feeling that it's a heavyweight
> solution for a tiny problem
>

I am hoping to reduce the code complexity (of rocopyup) after
we have the workdir/inodes/ index, because taking care of
rocopyup/rwcopyup races can be similar to taking care of
link/unlink/link races... we'll see how it goes.

The read pages performance overhead should be reasonable with
sharing pages.

The inode create/delete overhead is something we will need to measure,
but from my experience with xfs, I suspect that the cost is going to be
fair enough that some people would like to pay it to get the "tiny" problem
solved.

Also, the "tiny" problem is also going to be manifested with hardlinks
copy up, where it may need to be fixed anyway.
see this commit message for the details:
https://github.com/amir73il/linux/commit/62a16f3389187d3c3efa22293bf65cdb7bd619c5



> The non-starred ones don't seem too hard and should aim for 4.13.
>

Indeed. I am going to start with hardlinks and const d_ino soon.
The case of non-dir is easier to handle first because:
1. workdir/inodes/#lower_ino is a hard link to upper,
    so fewer follow by file handles involved
2. const d_ino for directory is not very interesting -
    'find' always uses stat() to get inode number of directory,
    so 'find -ino N' is not affected by non-const dir d_ino.

Cheers,
Amir.



[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]
  Powered by Linux