[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJfpegvEK9=aYdtpqFyT9QQAn5_ugpucd5JLuMrAO1uv8DnQ1w@mail.gmail.com>
Date: Fri, 21 Oct 2016 11:30:04 +0200
From: Miklos Szeredi <miklos@...redi.hu>
To: Amir Goldstein <amir73il@...il.com>
Cc: Vivek Goyal <vgoyal@...hat.com>,
"linux-unionfs@...r.kernel.org" <linux-unionfs@...r.kernel.org>,
linux-fsdevel <linux-fsdevel@...r.kernel.org>,
linux-kernel <linux-kernel@...r.kernel.org>,
Jeremy Eder <jeder@...hat.com>,
David Howells <dhowells@...hat.com>,
Gou Rao <grao@...tworx.com>, Vinod Jayaraman <jv@...tworx.com>,
Al Viro <viro@...iv.linux.org.uk>,
Dave Chinner <david@...morbit.com>
Subject: Re: [POC/RFC PATCH] overlayfs: fix data inconsistency at copy up
On Fri, Oct 21, 2016 at 11:13 AM, Amir Goldstein <amir73il@...il.com> wrote:
> I think it would be a good idea in general to stabilize the overlay ino/dev
> throughout copy-up, same as Miklos suggested to do for directories, to
> all files:
> pure upper uses upper ino + overlayfs dev
> non-pure upper uses lower ino + overlayfs dev
Making st_ino, st_dev and d_ino behave consistently would be the next big step.
The above scheme only works if lower and upper are on the same
filesystem. Otherwise there can be collisions between the lower and
upper inode numbers. Perhaps you meant:
- pure upper uses upper ino + upper dev
- non-pure upper uses lower ino + overlayfs dev
It works for the single lower layer case, but again breaks if there
are multiple lower layers. And d_ino in a merged directory could
still get us into trouble. And find -xdev would not do what you'd
expect with a "normal" filesystem.
So there doesn't appear to be any easy solutions to this...
Thanks,
Miklos
Powered by blists - more mailing lists