search

geckolinux / geckolinux-project

GeckoLinux bug tracker and documentation
https://geckolinux.github.io
209 stars 17 forks source link

btrfs filesystem default may cause fragmentation and performance issues due to COW #240

Closed greg-weber closed 3 years ago

greg-weber commented 3 years ago

Again thanks for fixing the issue with zstd and grub. When reading your fix and thinking of chattr -C instead of chattr -c, I remembered a possible issue for default btrfs filesystems caused by how CopyOnWrite write to disk.

This one I'm not sure if it still applies as btrfs has been worked on significantly. Also defragmentation on SSD isn't the same as a disk drive. For other reasons I already happen to use a different filesystem where my VMs or any torrents are stored. I did try gnome boxes and found performance issues with the default location using /home/user/.local/share/gnome-boxes/images on an Ubuntu 20.04 btrfs install. Sqlite used to be affected but I have not had to change anything yet wile using firefox and other programs that use sqlite.

It seems btrfs COW generally should be disabled for : -torrents -databases -virtual-machine disks

Copy-on-write doesn't play nice with databases or a file like a torrent or disk image that are constantly being written to and changed. At the very least it causes defragmentation.

Possible fix: chattr -R +C /home/username/Downloads chattr -R +C /home/username/.local/share/gnome-boxes/images chattr -R +C /home/username/VirtualBox\ VMs # This may not work due to space - I can't remember if \ is enough

Hopefully I'm mistaken and this is no longer an issue

greg-weber commented 3 years ago

Yeah this still is a poor report as it I wasn't able to confirm it. I didn't have time or expertise to test whether this will effect. (Ubuntu LTS 20.04 as I don't have a spare machine for bare metal geckolinux)---> On bare metal btrfs with COW enabled I had tried gnome-boxes and noticed slow performance. I ended up turning off COW and then cloning the VM, but cloning messed up configuration so no final comparison. May make sense to close for now as unconfirmed still

geckolinux commented 3 years ago

Thanks for mentioning this. Definitely one of the downsides of Btrfs is the lack of accurate and up-to-date information on the current gotchas and best practices.

I'm reasonably confident that the GeckoLinux defaults will be OK, because they don't stray far from the Calamares defaults. Basically, the GeckoLinux changes are compression across the board whether it's rotational or SSD, and LZO -> Zstd.

What I'm actually more concerned about is the Btrfs balance mechanism, which seems to have hosed one of my personal filesystems: https://www.reddit.com/r/openSUSE/comments/n9y116/btrfs_partition_goes_readonly_a_few_seconds_after/ Fortunately it only seems to happen under unusual usage scenarios with tons of snapshots.

So I guess we'll close this bug as unconfirmed and upstream. But I'll definitely be interested in seeing any reports of failures or Btrfs-specific bugs cropping up, and we'll make the needed changes if required.

geckolinux commented 3 years ago

Oh, and please feel free to write if you notice anything else, the constructive feedback is very much appreciated.

greg-weber commented 3 years ago

Yes it seems that accurate updated best practices and documented known issues are needed. BTRFS isn't quite at the level where you can set it and forget it. It could be a reason why I might move over to ZFS, or just ext4 if my use case doesn't suit it.

That seems like good practice to stick close to the defaults. That makes sense.

I looked at the BTRFS balance mechanism thread followed the link. After a hosed filesystem I can see why that is a concern. Too bad I can't offer something there. I would be a person who wants a lot of snapshots too and considered backing up from the snapshots. I had only heard vague warnings in my research as to avoid having a lot of snapshots.

I'll be in touch if I notice anything else that would be of use.