On 13.2.2017 21:03, Hans van Kranenburg wrote:
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`)
Sorry, I've lost this part:
$ btrfs version
btrfs-progs v4.9
# 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.
It looks you're right!
On a different machine:
# btrfs sub list / | grep -v lxc
ID 327 gen 1959587 top level 5 path mnt/reaver
ID 498 gen 593655 top level 5 path var/lib/machines
# btrfs sub list / -d | wc -l
0
# btrfs version
btrfs-progs v4.8.2
# uname -a
Linux nxserver 4.8.6-1-ARCH #1 SMP PREEMPT Mon Oct 31 18:51:30 CET 2016
x86_64 GNU/Linux
# mount | grep btrfs
/dev/vda1 on / type btrfs
(rw,relatime,nodatasum,nodatacow,space_cache,subvolid=5,subvol=/)
Then I've upgraded this machine and:
# btrfs sub list / | grep -v lxc
ID 327 gen 1959587 top level 5 path mnt/reaver
ID 498 gen 593655 top level 5 path var/lib/machines
# btrfs sub list / -d | wc -l
1
# btrfs sub list / -d
ID 5 gen 2186037 top level 0 path DELETED <======
1
# btrfs version
btrfs-progs v4.9
# uname -a
Linux nxserver 4.9.8-1-ARCH #1 SMP PREEMPT Mon Feb 6 12:59:40 CET 2017
x86_64 GNU/Linux
# mount | grep btrfs
/dev/vda1 on / type btrfs
(rw,relatime,nodatasum,nodatacow,space_cache,subvolid=5,subvol=/)
# 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.
I have not noticed this at all!
# btrfs fi show /
Label: none uuid: 859dec5c-850c-4660-ad99-bc87456aa309
Total devices 1 FS bytes used 134.23GiB
devid 1 size 200.00GiB used 200.00GiB path /dev/mapper/vg0-btrfsroot
# btrfs fi df /
Data, single: total=195.96GiB, used=131.58GiB
System, single: total=3.00MiB, used=48.00KiB
Metadata, single: total=4.03GiB, used=2.64GiB
GlobalReserve, single: total=512.00MiB, used=0.00B
After btrfs defrag there is no difference. btrfs fi show says still
200/200. I'll try to play with it.
--
Martin Mlynář
--
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
