* Re: Bug Report: Btrfs prompts "can't allocate space for delete" when block size arounds 512M [not found] <b501bcff-8be0-4303-8789-363fda4658e5@windriver.com> @ 2019-08-02 3:11 ` Hongzhi, Song 2019-09-04 2:36 ` Bug Report: Btrfs can't allocate space for delete " Hongzhi, Song 1 sibling, 0 replies; 4+ messages in thread From: Hongzhi, Song @ 2019-08-02 3:11 UTC (permalink / raw) To: linux-btrfs, josef, linux-kernel; +Cc: dsterba, ltp Add linux-kernel@vger.kernel.org. Ping... Thanks, --Hongzhi On 7/17/19 4:34 PM, Hongzhi, Song wrote: > Hi friends, > > *Description:* > > > One LTP testcase, fs_fill.c, fails on btrfs with kernel error when > unlink files on Btrfs device: > > "BTRFS warning (device loop0): could not allocate space for a > delete; will truncate on mount". > > > I found the loop block device formatted with btrfs roughly rangs > from 460M to 560M will cause the error. > > 256M and 1G all pass. > > > The fs_fill.c source code: > > [https://github.com/linux-test-project/ltp/blob/master/testcases/kernel/fs/fs_fill/fs_fill.c] > > > The fs_fill.c calls unlink which triggers the error. > > [https://github.com/linux-test-project/ltp/blob/e3457e42c1b93f54bb81da746eba314fd34ad40e/testcases/kernel/fs/fs_fill/fs_fill.c#L55] > > > [https://github.com/linux-test-project/ltp/blob/e3457e42c1b93f54bb81da746eba314fd34ad40e/lib/safe_macros.c#L358] > > > > *Error info:* > > The issue maybe not reproduced everytime but four fifths chance. > > fs_fill.c:53: INFO: Unlinking mntpoint/thread5/file0 > safe_macros.c:360: BROK: fs_fill.c:55: > unlink(mntpoint/thread10/file0) failed: ENOSPC > safe_macros.c:360: BROK: fs_fill.c:55: > unlink(mntpoint/thread11/file0) failed: ENOSPC > [62477.378848] BTRFS warning (device loop0): could not allocate > space for a delete; will truncate on mount > [62477.378905] BTRFS warning (device loop0): could not allocate > space for a delete; will truncate on mount > > > > *Kernel:* > > After v5.2-rc1, qemux86-64 > > # make -j40 ARCH=x86_64 CROSS_COMPILE=x86-64-gcc > use qemu to bootup kernel > > > *LTP:* > > master branch: I tested on 20190625 > Reproduce: > > // build Ltp > # cd Ltp-source > # ./build.sh > > // copy files to qemu > # cp runltp testcases/kernel/fs/fs_fill/fs_fill to qemu > > // login to qemu: > // adjust block device size to 512M > # 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 > > // execute testcase > # runltp -f fs -s fs_fill > > > *Analysis:* > > One new kernel commit contained in v5.2-rc1 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 > > > > > ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Bug Report: Btrfs can't allocate space for delete when block size arounds 512M [not found] <b501bcff-8be0-4303-8789-363fda4658e5@windriver.com> 2019-08-02 3:11 ` Bug Report: Btrfs prompts "can't allocate space for delete" when block size arounds 512M Hongzhi, Song @ 2019-09-04 2:36 ` Hongzhi, Song 2019-09-04 3:44 ` Hongzhi, Song 2019-09-04 8:03 ` Nikolay Borisov 1 sibling, 2 replies; 4+ messages in thread From: Hongzhi, Song @ 2019-09-04 2:36 UTC (permalink / raw) To: linux-btrfs, linux-kernel; +Cc: josef, dsterba Anybody notice this? --Hongzhi On 7/17/19 4:34 PM, Hongzhi, Song wrote: > Hi friends, > > *Description:* > > > One LTP testcase, fs_fill.c, fails on btrfs with kernel error when > unlink files on Btrfs device: > > "BTRFS warning (device loop0): could not allocate space for a > delete; will truncate on mount". > > > I found the loop block device formatted with btrfs roughly rangs > from 460M to 560M will cause the error. > > 256M and 1G all pass. > > > The fs_fill.c source code: > > [https://github.com/linux-test-project/ltp/blob/master/testcases/kernel/fs/fs_fill/fs_fill.c] > > > The fs_fill.c calls unlink which triggers the error. > > [https://github.com/linux-test-project/ltp/blob/e3457e42c1b93f54bb81da746eba314fd34ad40e/testcases/kernel/fs/fs_fill/fs_fill.c#L55] > > > [https://github.com/linux-test-project/ltp/blob/e3457e42c1b93f54bb81da746eba314fd34ad40e/lib/safe_macros.c#L358] > > > > *Error info:* > > The issue maybe not reproduced everytime but four fifths chance. > > fs_fill.c:53: INFO: Unlinking mntpoint/thread5/file0 > safe_macros.c:360: BROK: fs_fill.c:55: > unlink(mntpoint/thread10/file0) failed: ENOSPC > safe_macros.c:360: BROK: fs_fill.c:55: > unlink(mntpoint/thread11/file0) failed: ENOSPC > [62477.378848] BTRFS warning (device loop0): could not allocate > space for a delete; will truncate on mount > [62477.378905] BTRFS warning (device loop0): could not allocate > space for a delete; will truncate on mount > > > > *Kernel:* > > After v5.2-rc1, qemux86-64 > > # make -j40 ARCH=x86_64 CROSS_COMPILE=x86-64-gcc > use qemu to bootup kernel > > > *LTP:* > > master branch: I tested on 20190625 > Reproduce: > > // build Ltp > # cd Ltp-source > # ./build.sh > > // copy files to qemu > # cp runltp testcases/kernel/fs/fs_fill/fs_fill to qemu > > // login to qemu: > // adjust block device size to 512M > # 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 > > // execute testcase > # runltp -f fs -s fs_fill > > > *Analysis:* > > One new kernel commit contained in v5.2-rc1 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 > > > > > > ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Bug Report: Btrfs can't allocate space for delete when block size arounds 512M 2019-09-04 2:36 ` Bug Report: Btrfs can't allocate space for delete " Hongzhi, Song @ 2019-09-04 3:44 ` Hongzhi, Song 2019-09-04 8:03 ` Nikolay Borisov 1 sibling, 0 replies; 4+ messages in thread From: Hongzhi, Song @ 2019-09-04 3:44 UTC (permalink / raw) To: linux-btrfs, linux-kernel; +Cc: josef, dsterba I remake the test case to be more simply. And the send the new email. Thanks, --Hongzhi On 9/4/19 10:36 AM, Hongzhi, Song wrote: > Anybody notice this? > > --Hongzhi > > > On 7/17/19 4:34 PM, Hongzhi, Song wrote: >> Hi friends, >> >> *Description:* >> >> >> One LTP testcase, fs_fill.c, fails on btrfs with kernel error >> when unlink files on Btrfs device: >> >> "BTRFS warning (device loop0): could not allocate space for a >> delete; will truncate on mount". >> >> >> I found the loop block device formatted with btrfs roughly rangs >> from 460M to 560M will cause the error. >> >> 256M and 1G all pass. >> >> >> The fs_fill.c source code: >> >> [https://github.com/linux-test-project/ltp/blob/master/testcases/kernel/fs/fs_fill/fs_fill.c] >> >> >> The fs_fill.c calls unlink which triggers the error. >> >> [https://github.com/linux-test-project/ltp/blob/e3457e42c1b93f54bb81da746eba314fd34ad40e/testcases/kernel/fs/fs_fill/fs_fill.c#L55] >> >> >> [https://github.com/linux-test-project/ltp/blob/e3457e42c1b93f54bb81da746eba314fd34ad40e/lib/safe_macros.c#L358] >> >> >> >> *Error info:* >> >> The issue maybe not reproduced everytime but four fifths chance. >> >> fs_fill.c:53: INFO: Unlinking mntpoint/thread5/file0 >> safe_macros.c:360: BROK: fs_fill.c:55: >> unlink(mntpoint/thread10/file0) failed: ENOSPC >> safe_macros.c:360: BROK: fs_fill.c:55: >> unlink(mntpoint/thread11/file0) failed: ENOSPC >> [62477.378848] BTRFS warning (device loop0): could not allocate >> space for a delete; will truncate on mount >> [62477.378905] BTRFS warning (device loop0): could not allocate >> space for a delete; will truncate on mount >> >> >> >> *Kernel:* >> >> After v5.2-rc1, qemux86-64 >> >> # make -j40 ARCH=x86_64 CROSS_COMPILE=x86-64-gcc >> use qemu to bootup kernel >> >> >> *LTP:* >> >> master branch: I tested on 20190625 >> Reproduce: >> >> // build Ltp >> # cd Ltp-source >> # ./build.sh >> >> // copy files to qemu >> # cp runltp testcases/kernel/fs/fs_fill/fs_fill to qemu >> >> // login to qemu: >> // adjust block device size to 512M >> # 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 >> >> // execute testcase >> # runltp -f fs -s fs_fill >> >> >> *Analysis:* >> >> One new kernel commit contained in v5.2-rc1 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 >> >> >> >> >> >> > ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Bug Report: Btrfs can't allocate space for delete when block size arounds 512M 2019-09-04 2:36 ` Bug Report: Btrfs can't allocate space for delete " Hongzhi, Song 2019-09-04 3:44 ` Hongzhi, Song @ 2019-09-04 8:03 ` Nikolay Borisov 1 sibling, 0 replies; 4+ messages in thread From: Nikolay Borisov @ 2019-09-04 8:03 UTC (permalink / raw) To: Hongzhi, Song, linux-btrfs, linux-kernel; +Cc: David Sterba, josef On 4.09.19 г. 5:36 ч., Hongzhi, Song wrote: > Anybody notice this? > 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2019-09-04 8:03 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <b501bcff-8be0-4303-8789-363fda4658e5@windriver.com>
2019-08-02 3:11 ` Bug Report: Btrfs prompts "can't allocate space for delete" when block size arounds 512M Hongzhi, Song
2019-09-04 2:36 ` Bug Report: Btrfs can't allocate space for delete " Hongzhi, Song
2019-09-04 3:44 ` Hongzhi, Song
2019-09-04 8:03 ` Nikolay Borisov
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®