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

Stefan Bader stefan.bader at canonical.com
Wed Nov 15 10:51:54 UTC 2017


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 --------------
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/20171115/8c38d148/attachment.sig>


More information about the kernel-team mailing list