On 02/13/2017 12:26 PM, Martin Mlynář wrote: > > I've currently run into strange problem with BTRFS. I'm using it as my > daily driver as root FS. Nothing complicated, just few subvolumes and > incremental backups using btrbk. > > Now I've noticed that my btrfs root volume (absolute top, ID 5) is in > "deleting" state. As I've done some testing and googling it seems that > this should not be possible. > > [...] > > # btrfs sub list -ad /mnt/btrfs_root/ > ID 5 gen 257505 top level 0 path <FS_TREE>/DELETED I have heard rumours that this is actually a bug in the output of sub list itself. What's the version of your btrfs-progs? (output of `btrfs version`) > # mount | grep btr > /dev/mapper/vg0-btrfsroot on / type btrfs > (rw,noatime,nodatasum,nodatacow,ssd,discard,space_cache,subvolid=1339,subvol=/rootfs) > > /dev/mapper/vg0-btrfsroot on /mnt/btrfs_root type btrfs > (rw,noatime,nodatasum,nodatacow,ssd,discard,space_cache,subvolid=5,subvol=/) The rumour was that it had something to do with using space_cache=v2, which this example does not confirm. > # uname -a > Linux interceptor 4.9.6-1-ARCH #1 SMP PREEMPT Thu Jan 26 09:22:26 CET > 2017 x86_64 GNU/Linux > > # btrfs fi show / > Label: none uuid: 859dec5c-850c-4660-ad99-bc87456aa309 > Total devices 1 FS bytes used 132.89GiB > devid 1 size 200.00GiB used 200.00GiB path /dev/mapper/vg0-btrfsroot As a side note, all of your disk space is allocated (200GiB of 200GiB). Even while there's still 70GiB of free space scattered around inside, this might lead to out-of-space issues, depending on how badly fragmented that free space is. -- Hans van Kranenburg -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
