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

Daniel Axtens daniel.axtens at canonical.com
Mon Oct 30 06:53:21 UTC 2017


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.
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(-)

-- 
2.11.0





More information about the kernel-team mailing list