[SRU][Zesty][PATCH 00/10] LP#1728489: tar -x sometimes fails on overlayfs

Stefan Bader stefan.bader at canonical.com
Mon Nov 6 12:54:05 UTC 2017


On 30.10.2017 07:53, Daniel Axtens wrote:
> BugLink: https://bugs.launchpad.net/bugs/1728489
> 
> [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.

I would rather prefer to see the same minimal backport approach that has been
done for Xenial to be done in Zesty, too. Zesty is released and in SRU mode.
There should be rather strong reasons to dump a change that big into it.

-Stefan

> 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 (9):
>   ovl: check if all layers are on the same fs
>   ovl: store file handle of lower inode on copy up
>   ovl: use an auxiliary var for overlay root entry
>   ovl: lookup non-dir copy-up-origin by file handle
>   ovl: set the ORIGIN type flag
>   ovl: persistent inode number for directories
>   ovl: constant st_ino/st_dev across copy up
>   ovl: persistent inode numbers for upper hardlinks
>   ovl: update documentation w.r.t. constant inode numbers
> 
> Miklos Szeredi (1):
>   ovl: merge getattr for dir and nondir
> 
>  Documentation/filesystems/overlayfs.txt |   9 +-
>  fs/overlayfs/copy_up.c                  |  82 +++++++++++++++++++
>  fs/overlayfs/dir.c                      |  34 +-------
>  fs/overlayfs/inode.c                    |  64 ++++++++++++++-
>  fs/overlayfs/namei.c                    | 141 ++++++++++++++++++++++++++++++--
>  fs/overlayfs/overlayfs.h                |  41 ++++++++++
>  fs/overlayfs/ovl_entry.h                |   2 +
>  fs/overlayfs/super.c                    |   8 ++
>  fs/overlayfs/util.c                     |  17 +++-
>  9 files changed, 355 insertions(+), 43 deletions(-)
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ubuntu.com/archives/kernel-team/attachments/20171106/f615f0cc/attachment.sig>


More information about the kernel-team mailing list