Hi!
Not being able to delete a file on a filled filesystem sounds like a
filesystem bug to me. CCying Btrfs mailing list.
> Description:
>
> fs_fill fails on Btrfs when /dev/loop//*size = 512M*/.
> I tested other size, 256M 1G, all passed.
>
>
> Kernel:
>
> v5.2-rc1, qemux86-64
>
> |# make -j40 ARCH=x86_64 CROSS_COMPILE=x86-64-gcc use qemu to bootup kernel |
>
>
> LTP:
>
> master branch: date 20190625
>
>
> Reproduce:
>
> |build ltp source and cp ltp all outputs to qemu # vi runltp in
> function: create_block() dd if=/dev/zero of=${TMP}/test.img bs=1024
> count=262144 ---> dd if=/dev/zero of=${TMP}/test.img bs=1024
> count=524288 # runltp -f fs -s fs_fill |
>
>
> Issue:
>
> The issue maybe not reproduced everytime but four fifths chance.
>
> |safe_macros.c:358: BROK: fs_fill.c:67: unlink(mntpoint/thread9/file0)
> failed: ENOSPC safe_macros.c:358: BROK: fs_fill.c:67:
> unlink(mntpoint/thread4/file0) failed: ENOSPC [ 154.762502] BTRFS
> warning (device loop0): could not allocate space for a delete; will
> truncate on mount [ 155.691577] BTRFS warning (device loop0): could not
> allocate space for a delete; will truncate on mount [ 156.017697] BTRFS
> warning (device loop0): could not allocate space for a delete; will
> truncate on mount |
>
>
> Analysis:
>
> One new kernel commit contained in v5.2-rc1 introduces the issue.
>
> |commit c8eaeac7b734347c3afba7008b7af62f37b9c140 Author: Josef Bacik
> <jo...@toxicpanda.com> Date: Wed Apr 10 15:56:10 2019 -0400 btrfs:
> reserve delalloc metadata differently ...|
>
>
> Anyone's reply will be appreciated.
>
> --Hongzhi
>
> ||
--
Cyril Hrubis
chru...@suse.cz
