Messages in this thread | | | Subject | Re: Bug?: unlink cause btrfs error but other fs don't | From | "Hongzhi, Song" <> | Date | Wed, 4 Sep 2019 16:39:49 +0800 |
| |
Hi Nikolay,
>
There were multiple fixes from Josef recently improving btrfs enospc handling with tiny filesystems (which is generally not the targeted use case of btrfs). The code lives in https://github.com/kdave/btrfs-devel/commits/misc-next should you want to test it. Otherwise re-test after next merge windows when those patches are supposed to be merged for 5.4
>
Thank for your reply, I will keep eyes on the branch.
ps: this email is my simply testcase from ltp
--Hongzhi
On 9/4/19 4:02 PM, Hongzhi, Song wrote: > Hi , > > > *Kernel:* > > After v5.2-rc1, qemux86-64 > > make -j40 ARCH=x86_64 CROSS_COMPILE=x86-64-gcc > use qemu to bootup kernel > > > *Reproduce:* > > There is a test case failed on btrfs but success on other > fs(ext4,ext3), see attachment. > > > Download attachments: > > gcc test.c -o myout -Wall -lpthread > > copy myout and run.sh to your qemu same directory. > > on qemu: > > ./run.sh > > > I found the block device size with btrfs set 512M will cause the > error. > 256M and 1G all success. > > > *Error info:* > > "BTRFS warning (device loop0): could not allocate space for a > delete; will truncate on mount" > > > *Related patch:* > > I use git bisect to find the following patch introduces the issue. > > commit c8eaeac7b734347c3afba7008b7af62f37b9c140 > Author: Josef Bacik <josef@toxicpanda.com> > Date: Wed Apr 10 15:56:10 2019 -0400 > > btrfs: reserve delalloc metadata differently > ... > > > Anyone's reply will be appreciated. > > --Hongzhi >
| |