On 2019/12/21 下午6:59, Swâmi Petaramesh wrote: > Hi list, > > After writing files and snapshots WITHOUT errors on an external BTRFS FS > with 500+ GB of free space, using kernel 5.4.5-arch1-1, I dismount the > FS then remount it normally, and then it says the FS has 0 space free > left ! > > Checking the disk on another machine with > > [moksha ~]# uname -r > 5.4.2-1-MANJARO > > And... How can this be ? > > root@moksha:~# df -h /run/media/myself/MyVolume > Filesystem Size Used Avail Use% Mounted on > /dev/mapper/luks-xxxxxxxxx-yyyy-zzzz-tttt-wwwwwww 1,9T 1,2T 0 100% > /run/media/myself/MyVolume A known regression introduced in v5.4. The new metadata over-commit behavior conflicts with an existing check in btrfs_statfs(). It is completely a runtime false behavior, and had *no* other bad effect. If you feel like to address it with off-tree patch, there is a quick patch to address it: https://patchwork.kernel.org/patch/11293419/ > > root@moksha:~# btrfs fi sh > Label: 'MyVolume' uuid: xxxxxxxxx-yyyy-zzzz-tttt-wwwwwww > Total devices 1 FS bytes used 1.19TiB > devid 1 size 1.82TiB used 1.20TiB path > /dev/mapper/luks-xxxxxxxxx-yyyy-zzzz-tttt-wwwwwww > > root@moksha:~# btrfs fi df /run/media/myself/MyVolume > Data, single: total=1.18TiB, used=1.18TiB > System, DUP: total=8.00MiB, used=160.00KiB > Metadata, DUP: total=7.00GiB, used=6.88GiB > GlobalReserve, single: total=512.00MiB, used=0.00B > > root@moksha:~# umount /run/media/myself/MyVolume > > root@moksha:~# btrfs check > /dev/mapper/luks-xxxxxxxxx-yyyy-zzzz-tttt-wwwwwww > Opening filesystem to check... > Checking filesystem on /dev/mapper/luks-xxxxxxxxx-yyyy-zzzz-tttt-wwwwwww > UUID: xxxxxxxxx-yyyy-zzzz-tttt-wwwwwww > [1/7] checking root items > [2/7] checking extents > [3/7] checking free space cache > [4/7] checking fs roots > > (Still running since a while, no errors...) Running a fsck is always a good behavior, although in this case, it shouldn't cause any corruption. Thanks, Qu > > TIA for any help. > > Kind regards. >
