NACK: [SRU][Xenial][PATCH 0/2] LP#1728489: tar -x sometimes fails on overlayfs

[Daniel Axtens]

Hi all,

Apologies - my screw-up.

The aim is to have a 2 patch series for both Xenial and Zesty.

I will resubmit both with the correct headers and will look for ways to
tighten up my personal processes so as not to be so confusing in future.

Regards,
Daniel

On Wed, Nov 15, 2017 at 9:51 PM, Stefan Bader <stefan.bader at canonical.com>
wrote:

> On 15.11.2017 11:43, Kleber Souza wrote:
> > A v2 of this patchset has been sent to the mailing list.
> >
> > On 10/30/17 07:56, Daniel Axtens wrote:
> >> [SRU Justification]
> >>
> >> [Impact]
> >>
> >> A user is seeing failures from extracting tar archives on overlay
> >> filesystems on the 4.4 kernel in constrained environments. The error
> >> presents as:
> >>
> >> `tar: ./deps/0/bin: Directory renamed before its status could be
> extracted`
> >>
> >> Following this thread
> >> (https://www.spinics.net/lists/linux-unionfs/msg00856.html), it appears
> >> that this occurs when entries in the kernel's inode cache are
> >> reclaimed, and subsequent lookups return new inode numbers.
> >>
> >> Further testing showed that when setting
> >> `/proc/sys/vm/vfs_cache_pressure` to 0 (don't allow the kernel to
> >> reclaim inode cache entries due to memory pressure) the error does not
> >> recur, supporting the hypothesis that cache entries are being
> >> evicted. However, this setting may lead to a kernel OOM so is not a
> >> reasonable workaround even temporarily.
> >>
> >> The error cannot be reproduced on a 4.13 kernel, due to the series at
> >> https://www.spinics.net/lists/linux-fsdevel/msg110235.html. The
> >> particular relevant commit is
> >> b7a807dc2010334e62e0afd89d6f7a8913eb14ff, which needs a couple of
> >> dependencies.
> >>
> >> [Fix]
> >> For Zesty, backport the entire series.
> >> For Xenial, where a full backport is not feasible, backport the key
> >> commit and the short list of dependencies.
> >>
> >> [Testcase]
> >>
> >> # Testing this bug
> >>
> >> The testcase for this particular bug is simple - create an overlay
> >> filesystem with all layers on the same underlying file system, and
> >> then see if the inode of a directory is constant across dropping the
> >> caches:
> >>
> >> mkdir -p /upper/upper /upper/work /lower
> >> mount -t overlay none /mnt -o lowerdir=/lower,upperdir=/
> upper/upper,workdir=/upper/work
> >> cd /mnt
> >> mkdir a
> >> stat a # observe inode number
> >> echo 2 > /proc/sys/vm/drop_caches
> >> stat a # compare inode number
> >>
> >> If the inode number is the same, the fix is successful.
> >>
> >> # Regression testing
> >>
> >> I have run the unionmount test suite from
> >> https://git.infradead.org/users/dhowells/unionmount-testsuite.git in
> >> overlay mode (./run --ov), and verified that it still passes.
> >>
> >> (The series cover letter mentions a fork of the test suite at
> >> https://github.com/amir73il/unionmount-testsuite/commits/
> overlayfs-devel. I
> >> have *not* attempted to get this running: it assumes a range of
> >> changes that are not present in our kernels.)
> >>
> >> [Regression Potential]
> >>
> >> As this changes overlayfs, there is potential for regression in the
> >> form of unexpected breakages to overlaysfs behaviour.
> >>
> >> I think this is adequately addressed by the regression testing.
> >>
> >> One option to reduce the regression potential on Zesty is to reduce
> >> the set of patches applied - rather than including the whole series we
> >> could include just the patches to solve this bug, which are much
> >> easier to inspect for correctness.
> >>
> >> Amir Goldstein (2):
> >>   ovl: check if all layers are on the same fs
> >>   ovl: persistent inode number for directories
> >>
> >>  fs/overlayfs/dir.c       | 29 ++++++++++++++++++++++++++++-
> >>  fs/overlayfs/overlayfs.h |  1 +
> >>  fs/overlayfs/super.c     | 17 +++++++++++++++++
> >>  3 files changed, 46 insertions(+), 1 deletion(-)
> >>
> >
> Not sure the v2 was really Xenial but agreed its confusing...
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/kernel-team/attachments/20171116/e5d19de5/attachment.html>