Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1505914
| From | Amir Goldstein <amir73il@gmail.com> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [POC/RFC PATCH] overlayfs: fix data inconsistency at copy up |
| Date | 2016-10-21 15:20 +0200 |
| Message-ID | <suHTP-60l-7@gated-at.bofh.it> (permalink) |
| References | <srrVg-52p-33@gated-at.bofh.it> <susrL-45X-1@gated-at.bofh.it> <suE9B-3xe-61@gated-at.bofh.it> <suEsX-3Ew-55@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On Fri, Oct 21, 2016 at 12:30 PM, Miklos Szeredi <miklos@szeredi.hu> wrote: > On Fri, Oct 21, 2016 at 11:13 AM, Amir Goldstein <amir73il@gmail.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... > Not for the general case there isn't, but I was actually thinking of the docker case and there is a lot that can be done for the use case of lower and upper on the same fs to make overlayfs more compliant. Since it's quite a common use case, perhaps its worth the special treatment. Amir.
Back to linux.kernel | Previous | Next — Previous in thread | Find similar | Unroll thread
Re: [POC/RFC PATCH] overlayfs: fix data inconsistency at copy up Vivek Goyal <vgoyal@redhat.com> - 2016-10-20 22:50 +0200
Re: [POC/RFC PATCH] overlayfs: fix data inconsistency at copy up Vivek Goyal <vgoyal@redhat.com> - 2016-10-20 23:00 +0200
Re: [POC/RFC PATCH] overlayfs: fix data inconsistency at copy up Amir Goldstein <amir73il@gmail.com> - 2016-10-21 11:00 +0200
Re: [POC/RFC PATCH] overlayfs: fix data inconsistency at copy up Vivek Goyal <vgoyal@redhat.com> - 2016-10-21 22:20 +0200
Re: [POC/RFC PATCH] overlayfs: fix data inconsistency at copy up Amir Goldstein <amir73il@gmail.com> - 2016-10-22 09:30 +0200
Re: [POC/RFC PATCH] overlayfs: fix data inconsistency at copy up Amir Goldstein <amir73il@gmail.com> - 2016-10-22 17:40 +0200
Re: [POC/RFC PATCH] overlayfs: fix data inconsistency at copy up Miklos Szeredi <miklos@szeredi.hu> - 2016-10-24 10:20 +0200
Re: [POC/RFC PATCH] overlayfs: fix data inconsistency at copy up Miklos Szeredi <miklos@szeredi.hu> - 2016-10-21 11:20 +0200
Re: [POC/RFC PATCH] overlayfs: fix data inconsistency at copy up Vivek Goyal <vgoyal@redhat.com> - 2016-10-21 15:40 +0200
Re: [POC/RFC PATCH] overlayfs: fix data inconsistency at copy up Amir Goldstein <amir73il@gmail.com> - 2016-10-21 11:20 +0200
Re: [POC/RFC PATCH] overlayfs: fix data inconsistency at copy up Miklos Szeredi <miklos@szeredi.hu> - 2016-10-21 11:40 +0200
Re: [POC/RFC PATCH] overlayfs: fix data inconsistency at copy up Amir Goldstein <amir73il@gmail.com> - 2016-10-21 15:20 +0200
csiph-web