Re: [PATCH 0/2] Fix failing overlay nonsamefs fstests

Miklos Szeredi
2018-04-23T19:05:03Z

On Mon, Apr 23, 2018 at 5:57 PM, Amir Goldstein <amir73il@gmail.com> wrote:
> On Mon, Apr 23, 2018 at 8:12 AM, Miklos Szeredi <miklos@szeredi.hu> wrote:
>> On Mon, Apr 23, 2018 at 4:50 PM, Amir Goldstein <amir73il@gmail.com> wrote:
>>> On Mon, Apr 23, 2018 at 6:37 AM, Miklos Szeredi <miklos@szeredi.hu> wrote:
>>>> On Wed, Apr 18, 2018 at 4:30 PM, Amir Goldstein <amir73il@gmail.com> wrote:
>>>>> On Wed, Apr 18, 2018 at 5:23 PM, Miklos Szeredi <miklos@szeredi.hu> wrote:
>>>>>> On Wed, Apr 18, 2018 at 4:16 PM, Amir Goldstein <amir73il@gmail.com> wrote:
>>>>>>
>>>>>>> FYI, Miklos has a patch set in review to fix the last of the
>>>>>>> non-standard behavior tracking test that is still failing (overlay/016).
>>>>>>> After that patch set is merged, all overlay tests will be expected to
>>>>>>> pass on master - new era ;-)
>>>>>>
>>>>>> Oh, we can write new tests that don't pass ;)
>>>>
>>>> Another one:
>>>>
>>>> fstat() returns incorrect st_ctime after unlink of a lower file/directory.
>>>>
>>>> Alternative fixes:
>>>>
>>>> 1) take some attributes from whiteout
>>>>
>>>> 2) metacopy up to tmpfile
>
> I have patches to copy up to an "orphan index":
> https://github.com/amir73il/linux/commits/ovl-rocopyup
>
> combine that with metacopy and you have a ready and
> inexpensive place holder for st_ctime of unlinked file.

There are more bugs related to this. For example the following
sequence will give a strange EEXIST error:

fd = open(path, O_RDONLY);
unlink(path);
fchmod(fd, 0400);

The reason is, fchmod will try to copy up the lower file, but finds a
whiteout on the upper layer, so the copy-up fails.

Actually, after unlink (last unlink, to be precise) we don't need a
physical file, any metadata changes can just go into the overlay inode
(ctime, atime, mode, uid, gid). We just need to add a flag indicating
that the overlay inode is the authoritative source of metadata and
make sure any metadata changes go to the overlay inode.

And there's fsetxattr and fremovexattr. Hmm. We can also store
xattrs in memory, but that is becoming a bit complicated... Oh well,
we can just postpone the tmpfile copyup until this happens.

Thanks,
Miklos