Re: Understanding "btrfs filesystem usage"

2018-10-29 Thread Hugo Mills
On Mon, Oct 29, 2018 at 05:57:10PM -0400, Remi Gauvin wrote: > On 2018-10-29 02:11 PM, Ulli Horlacher wrote: > > I want to know how many free space is left and have problems in > > interpreting the output of: > > > > btrfs filesystem usage > > btrfs filesystem df > > btrfs filesystem show > > >

Re: Understanding "btrfs filesystem usage"

2018-10-29 Thread Remi Gauvin
On 2018-10-29 02:11 PM, Ulli Horlacher wrote: > I want to know how many free space is left and have problems in > interpreting the output of: > > btrfs filesystem usage > btrfs filesystem df > btrfs filesystem show > > In my not so humble opinion, the filesystem usage command has the easiest

Understanding "btrfs filesystem usage"

2018-10-29 Thread Ulli Horlacher
I want to know how many free space is left and have problems in interpreting the output of: btrfs filesystem usage btrfs filesystem df btrfs filesystem show In detail: root@diaspora:~# btrfs filesystem usage /local Overall: Device size: 883.51GiB Device allocated:

Re: [PATCH v2] btrfs: Fix error handling in btrfs_cleanup_ordered_extents

2018-10-29 Thread Nikolay Borisov
On 29.10.18 г. 14:21 ч., Nikolay Borisov wrote: > > > On 29.10.18 г. 9:51 ч., Nikolay Borisov wrote: >> >> >> On 29.10.18 г. 7:53 ч., Qu Wenruo wrote: >>> [snip] > The cause sounds valid, however would you please explain more about how > such cleaning on unrelated delalloc range

Re: [PATCH v2] btrfs: Fix error handling in btrfs_cleanup_ordered_extents

2018-10-29 Thread Nikolay Borisov
On 29.10.18 г. 9:51 ч., Nikolay Borisov wrote: > > > On 29.10.18 г. 7:53 ч., Qu Wenruo wrote: >> [snip] The cause sounds valid, however would you please explain more about how such cleaning on unrelated delalloc range happens? >>> >>> So in my case the following happened - 2 block

Re: [PATCH] fstests: btrfs/057: Fix false alerts due to orphan files

2018-10-29 Thread Filipe Manana
On Mon, Oct 29, 2018 at 6:35 AM Qu Wenruo wrote: > > For latest kernel, there is a chance that btrfs/057 reports false > errors. > > The false error would look like: > btrfs/057 4s ... - output mismatch (see > /home/adam/xfstests-dev/results//btrfs/057.out.bad) > --- tests/btrfs/057.out

Re: [PATCH] fstests: btrfs/057: Fix false alerts due to orphan files

2018-10-29 Thread Filipe Manana
On Mon, Oct 29, 2018 at 11:33 AM Qu Wenruo wrote: > > > > On 2018/10/29 下午5:52, Filipe Manana wrote: > > On Mon, Oct 29, 2018 at 6:31 AM Qu Wenruo wrote: > >> > >> For latest kernel, there is a chance that btrfs/057 reports false > >> errors. > > > > By latest kernel you mean 4.20? > > I mean

Re: [PATCH] fstests: btrfs/057: Fix false alerts due to orphan files

2018-10-29 Thread Qu Wenruo
On 2018/10/29 下午5:52, Filipe Manana wrote: > On Mon, Oct 29, 2018 at 6:31 AM Qu Wenruo wrote: >> >> For latest kernel, there is a chance that btrfs/057 reports false >> errors. > > By latest kernel you mean 4.20? I mean almost all kernels. > >> >> The false error would look like: >>

Re: [PATCH] fstests: btrfs/057: Fix false alerts due to orphan files

2018-10-29 Thread Filipe Manana
On Mon, Oct 29, 2018 at 6:31 AM Qu Wenruo wrote: > > For latest kernel, there is a chance that btrfs/057 reports false > errors. By latest kernel you mean 4.20? > > The false error would look like: > btrfs/057 4s ... - output mismatch (see >

[PATCH] fstests: fix fssum to actually ignore file holes when supposed to

2018-10-29 Thread fdmanana
From: Filipe Manana Unless the '-s' option is passed to fssum, it should not detect file holes and have their existence influence the computed checksum for a file. This tool was added to test btrfs' send/receive feature, so that it checks for any metadata and data differences between the

[PATCH] Btrfs: fix missing data checksums after a ranged fsync (msync)

2018-10-29 Thread fdmanana
From: Filipe Manana Recently we got a massive simplification for fsync, where for the fast path we no longer log new extents while their respective ordered extents are still running. However that simplification introduced a subtle regression for the case where we use a ranged fsync (msync).

Re: a new kind of "No space left on device" error

2018-10-29 Thread Henk Slager
On Mon, Oct 29, 2018 at 7:20 AM Dave wrote: > > This is one I have not seen before. > > When running a simple, well-tested and well-used script that makes > backups using btrfs send | receive, I got these two errors: > > At subvol snapshot > ERROR: rename o131621-1091-0 -> >

Re: [PATCH v2] btrfs: Fix error handling in btrfs_cleanup_ordered_extents

2018-10-29 Thread Nikolay Borisov
On 29.10.18 г. 7:53 ч., Qu Wenruo wrote: > [snip] >>> The cause sounds valid, however would you please explain more about how >>> such cleaning on unrelated delalloc range happens? >> >> So in my case the following happened - 2 block groups were created as >> delalloc ranges in the - 0-1m and

[PATCH] fstests: btrfs/057: Fix false alerts due to orphan files

2018-10-29 Thread Qu Wenruo
For latest kernel, there is a chance that btrfs/057 reports false errors. The false error would look like: btrfs/057 4s ... - output mismatch (see /home/adam/xfstests-dev/results//btrfs/057.out.bad) --- tests/btrfs/057.out 2017-08-21 09:25:33.1 +0800 +++

[PATCH] fstests: btrfs/057: Fix false alerts due to orphan files

2018-10-29 Thread Qu Wenruo
For latest kernel, there is a chance that btrfs/057 reports false errors. The false error would look like: btrfs/057 4s ... - output mismatch (see /home/adam/xfstests-dev/results//btrfs/057.out.bad) --- tests/btrfs/057.out 2017-08-21 09:25:33.1 +0800 +++

a new kind of "No space left on device" error

2018-10-29 Thread Dave
This is one I have not seen before. When running a simple, well-tested and well-used script that makes backups using btrfs send | receive, I got these two errors: At subvol snapshot ERROR: rename o131621-1091-0 -> usr/lib/node_modules/node-gyp/gyp/pylib/gyp/MSVSVersion.py failed: No space left