3 ms·
> ZFS & BTRFS both have native FS checksumming, I don't think there's a strong reason not to use it, except maybe in a contained embedded context. There are ma
by traceroute66 2y ago
> ZFS & BTRFS both have native FS checksumming, I don't think there's a strong reason not to use it, except maybe in a contained embedded context.
There are many good reasons not to use BTRFS. :)
Also ZFS is hell to use if you're not on an OS that has native support. You become reliant on e.g. kernel modules on Linux , and on Debian this means using Backports which is not something any sensible sysadmin wants to do because it introduces the hell of having a mismatch of all sorts of software unless you spend your life defining exclusions in the apt config.
Also in terms of SQLite, ZFS/BTRFS have no understanding of what's running on them. Personally, when it comes to databases I'd rather the database does its integrity checks. If the OS does some too that's great, but the database blindly assuming the OS will do integrity checking is not a good look in my book.
- bradfa 2y agoWhat exactly are the reasons to not use btrfs?
- chasil 2y agoWhile btrfs is stable, it will not run heavy database loads well with the default settings. https://archive.ph/dqFgh https://archive.ph/dqFgh Oracle explicitly does not support brtfs for their database.
- bradfa 2y agoThat article is from 9 years ago. Is there any more recent review which comes to similar conclusions? But also, if you’re running sqlite, your main goal is probably not to be a database server but to do some other primary objective that happens to benefit from using a database for some things.
- chasil 2y agoI am not trying to run oltp on btrfs, so I don't personally need more recent knowledge. A quick search suggests: https://news.ycombinator.com/item?id=10257466 https://news.ycombinator.com/item?id=10257466 I am sure that you will find far more detail in your own research, should this motivate you. Good luck!
- taffer 2y agoHere are some articles from 2022 and 2023. Btrfs database performance is still a disaster. [1] https://www.enterprisedb.com/blog/postgres-vs-file-systems-performance-comparison https://www.enterprisedb.com/blog/postgres-vs-file-systems-p... [2] https://www.phoronix.com/review/bcachefs-benchmarks-linux67 https://www.phoronix.com/review/bcachefs-benchmarks-linux67
- oarsinsync 2y ago> on Debian this means using Backports which is not something any sensible sysadmin wants to do because it introduces the hell of having a mismatch of all sorts of software unless you spend your life defining exclusions in the apt config. root@nas:/etc/apt/preferences.d# cat 80_kernel Package: linux-image-amd64 linux-headers-amd64 linux-kbuild-* Pin: release n=bullseye-backports Pin-Priority: 1000 root@nas:/etc/apt/preferences.d# cat 90_zfs Package: libnvpair* libuutil* libzfs* libzpool* spl-dkms zfs-* zfsutils-linux zfsutils-linux-dev Pin: release n=bullseye-backports Pin-Priority: 1000 root@nas:/etc/apt/preferences.d# cat 1000_backports Package: * Pin: release n=bullseye-backports Pin-Priority: 10 Pretty sure this is well documented in many places, I definitely didn’t invent this wheel myself. Been running zfs on Debian this way for the last 3 releases. Had one instance of drama when the kernel was updated before the zfs package was updated, making me need to downgrade the kernel, which was a faff for sure. The benefits of using ZFS in my environment greatly outweigh the downsides of using backports. I vastly prefer Debian to alternatives, so here we are (for me).