4 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. Many years 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. Many years ago ZFS checksums helped me figured out I had a bad DIMM.

lxgr 2y ago
There is: It’s already done at the layer below the file system. In the best case, repeating it at the FS layer wastes performance; in the worst case, it causes confusion as to which layer has to do it and then maybe nobody does. For the same reason, e.g. HTTP doesn’t have a checksum either, and IPv6 even got rid of its header checksum.
- anotherhue 2y ago
  You mean the disk controller or something else? I had not heard of that.
  - roncesvalles 2y ago
    Most modern hard drives (and all SSDs iirc) have block-level ECC.
- oarsinsync 2y ago
  HTTP depends on the TCP and Ethernet layer checksums, which is not great. At today’s bitrates, it is remarkable how frequent a bitflip can occur without invalidating the TCP or Ethernet checksums. HTTPS effectively gets integrity validation by default, as TLS takes care of that. TLS is much more effective at this than the checksums are.
chasil 2y ago
The problem with btrfs is that is does not work well with databases without careful adjustment. https://archive.ph/dqFgh https://archive.ph/dqFgh
- anotherhue 2y ago
  ZFS also but I don't think this applies to SQLite, more to 'real' DBs like PSQL.
  - chasil 2y ago
    There is an Oracle zfs tuning guide for the eponymous database. I would look at that if I wanted good performance for postgres or sqlite. https://docs.oracle.com/cd/E36784_01/html/E36845/chapterzfs-db2.html https://docs.oracle.com/cd/E36784_01/html/E36845/chapterzfs-... Google also returned zfs general database tuning: https://docs.oracle.com/en/operating-systems/solaris/oracle-solaris/11.4/tuning/tuning-zfs-database-products.html https://docs.oracle.com/en/operating-systems/solaris/oracle-...
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 ago
  What exactly are the reasons to not use btrfs?
  - chasil 2y ago
    While 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 ago
      That 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 ago
        I 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!
jandrewrogers 2y ago
In the context of databases there are a few issues with relying on the filesystem for checksums: - The default checksum algorithms used in many filesystems are too weak (e.g. CRC32), you really want 128-bits for modern databases. - While some filesystems give you a selection of checksum algorithms ranging from weak to very strong (e.g. SHA256), the databases like SQLite are often deployed in an environment where you have no control over the algorithm selected. - The checksum algorithms available in most filesystems do not provide adequate performance on modern storage hardware. It is much easier to evolve these in database engines than in the filesystem. - Filesystem suitability for database workloads varies widely. Few people are going to trade the performance and scalability of XFS for the built-in integrity mechanisms of ZFS. Implementing checksums in the database gets you the best of both worlds. Also databases are not always deployed on filesystems, so you need checksums for these cases. From a database engineering perspective, the checksumming in filesystems to the extent it exists is often not fit for purpose. Many databases implement their own integrity mechanisms for this reason.

lxgr 2y ago

There is: It’s already done at the layer below the file system. In the best case, repeating it at the FS layer wastes performance; in the worst case, it causes confusion as to which layer has to do it and then maybe nobody does. For the same reason, e.g. HTTP doesn’t have a checksum either, and IPv6 even got rid of its header checksum.

anotherhue 2y ago
You mean the disk controller or something else? I had not heard of that.
- roncesvalles 2y ago
  Most modern hard drives (and all SSDs iirc) have block-level ECC.
oarsinsync 2y ago
HTTP depends on the TCP and Ethernet layer checksums, which is not great. At today’s bitrates, it is remarkable how frequent a bitflip can occur without invalidating the TCP or Ethernet checksums. HTTPS effectively gets integrity validation by default, as TLS takes care of that. TLS is much more effective at this than the checksums are.

chasil 2y ago

The problem with btrfs is that is does not work well with databases without careful adjustment. https://archive.ph/dqFgh https://archive.ph/dqFgh

anotherhue 2y ago
ZFS also but I don't think this applies to SQLite, more to 'real' DBs like PSQL.
- chasil 2y ago
  There is an Oracle zfs tuning guide for the eponymous database. I would look at that if I wanted good performance for postgres or sqlite. https://docs.oracle.com/cd/E36784_01/html/E36845/chapterzfs-db2.html https://docs.oracle.com/cd/E36784_01/html/E36845/chapterzfs-... Google also returned zfs general database tuning: https://docs.oracle.com/en/operating-systems/solaris/oracle-solaris/11.4/tuning/tuning-zfs-database-products.html https://docs.oracle.com/en/operating-systems/solaris/oracle-...

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 ago
What exactly are the reasons to not use btrfs?
- chasil 2y ago
  While 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 ago
    That 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 ago
      I 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!

jandrewrogers 2y ago

In the context of databases there are a few issues with relying on the filesystem for checksums: - The default checksum algorithms used in many filesystems are too weak (e.g. CRC32), you really want 128-bits for modern databases. - While some filesystems give you a selection of checksum algorithms ranging from weak to very strong (e.g. SHA256), the databases like SQLite are often deployed in an environment where you have no control over the algorithm selected. - The checksum algorithms available in most filesystems do not provide adequate performance on modern storage hardware. It is much easier to evolve these in database engines than in the filesystem. - Filesystem suitability for database workloads varies widely. Few people are going to trade the performance and scalability of XFS for the built-in integrity mechanisms of ZFS. Implementing checksums in the database gets you the best of both worlds. Also databases are not always deployed on filesystems, so you need checksums for these cases. From a database engineering perspective, the checksumming in filesystems to the extent it exists is often not fit for purpose. Many databases implement their own integrity mechanisms for this reason.