On 09/19/2018 10:04 PM, Martin Steigerwald wrote: > Hans van Kranenburg - 19.09.18, 19:58: >> However, as soon as we remount the filesystem with space_cache=v2 - >> >>> writes drop to just around 3-10 MB/s to each disk. If we remount to >>> space_cache - lots of writes, system unresponsive. Again remount to >>> space_cache=v2 - low writes, system responsive. >>> >>> That's a huuge, 10x overhead! Is it expected? Especially that >>> space_cache=v1 is still the default mount option? >> >> Yes, that does not surprise me. >> >> https://events.static.linuxfound.org/sites/events/files/slides/vault20 >> 16_0.pdf >> >> Free space cache v1 is the default because of issues with btrfs-progs, >> not because it's unwise to use the kernel code. I can totally >> recommend using it. The linked presentation above gives some good >> background information. > > What issues in btrfs-progs are that? Missing code to make offline changes to a filesystem that has a free space tree. So when using btrfstune / repair / whatever you first need to remove the whole free space tree with a command, and then add it back on the next mount. For me personally that's not a problem (I don't have to make offline changes), but I understand that having that situation out of the box for every new user would be a bit awkward. > I am wondering whether to switch to freespace tree v2. Would it provide > benefit for a regular / and /home filesystems as dual SSD BTRFS RAID-1 > on a laptop? As shown in the linked presentation, it provides benefit on a largeish filesystem and if your writes are touching a lot of different block groups (since v1 writes out the full space cache for all of them on every transaction commit). I'd say, it provides benefit as soon as you encounter filesystem delays because of it, and as soon as you see using it eases the pain a lot. So, yes, that's your case. -- Hans van Kranenburg
