4 ms·

A ZFS block is 128 KB by default (smaller if the file is < 128 KB, but can also be larger if you manually configure it). So a ZFS block is even larger than a b

A ZFS block is 128 KB by default (smaller if the file is < 128 KB, but can also be larger if you manually configure it). So a ZFS block is even larger than a bcachefs "extent".

mastax 3y ago
Well yes, my point is that (counter to GP) ZFS doesn't combine together multiple blocks into a compression extent, rather it uses larger blocks by default.
- someplaceguy 3y ago
  ZFS's larger blocks you are referring to are the logical block size, which is the size unit for compression among other things. I don't know much about bcachefs, but as I understand it, a logical block in ZFS is equivalent to a bcachefs extent (in terms of compression, at least) and a ZFS physical block is equivalent to a (possibly empty) set of bcachefs blocks. As an example, in terms of actual on-disk storage, a 128 KB logical block in ZFS can be compressed down to (for example) a 3.5 KB "physical" block and it will only actually consume 3.5 KB of disk space (surprisingly, the block size of a ZFS physical block doesn't have to be a power of 2!). That said, if you have 4 KB-sector disks then you should probably use a physical block size granularity of 4 KB for your ZFS pool rather than 512 bytes. So, regardless of the file size, an on-disk ZFS block can actually occupy anywhere from 0 bytes up to 1 MB, with a granularity of up to 512 bytes, depending on how much it is compressed, what the physical block size granularity of the ZFS pool is and what you've selected as the recordsize property (i.e. the logical block size) for the corresponding filesystem in the pool.
  - rincebrain 3y ago
    16M, not 1M.
    - someplaceguy 3y ago
      Thanks for the correction. The `zfsprops` man page should be updated to reflect that...
      - rincebrain 3y ago
        It has been. The default was to limit it to 1M in case there were weird edge cases with the larger sizes (16M is the largest it'll encode on disk without a format change, IIRC), with larger sizes behind a tunable, but after a few years of people who knew this twiddling it, the default in 2.2 will be that the tunable is set to 16M.
  - 5e92cb50239222b 3y ago
    > if you have 4 KB-sector disks then you should probably use a physical block size granularity of 4 KB for your ZFS pool rather than 512 bytes According to Allan Jude (OpenZFS & FreeBSD developer), you should never use 512-byte recordsize even on an HDD with 512-byte sectors. Always start from 4 KiBs, probably even from 8. https://klarasystems.com/articles/tuning-recordsize-in-openzfs https://klarasystems.com/articles/tuning-recordsize-in-openz...
    - someplaceguy 3y ago
      > you should never use 512-byte recordsize even on an HDD with 512-byte sectors I think you meant to refer to the pool's sector size (i.e. "ashift" property) rather than the recordsize. I agree, but I wouldn't say "never", as that's too strong a word. It would be useful to use a 512-byte ZFS pool sector size even when the HDD uses 4K sectors if you care a lot about disk space efficiency but don't care at all about performance or HDD wear (for example, if you plan to use a ZFS pool almost exclusively read-only). That said, I would also recommend a 4K pool sector size in almost all cases, as HDD space is cheap.
    - rincebrain 3y ago
      I don't think that post is saying that. I think that post is warning you that it's immutable once done. If you want to be more flexible in the future and can't be sure you won't need to use 4kn/512e disks at some point, yes, use 4kn (or with all SSD storage it gets even messier). But using 512b can be a significant gain on space efficiency for some people.
  - mastax 3y ago
    I understand all of that. None of that disagrees with what I have said. I think we're talking past each other. In a practical sense I agree the two filesystems achieve an essentially identical result through very similar methods, as you have said. I am making a point specifically about the details of the implementation logic of the two filesystems. Bcachefs (as I understand it) combines multiple smaller blocks into a larger extent. ZFS only has one raw record and its corresponding on-disk compressed record, whose size is rounded up to ashift.

A ZFS block is 128 KB by default (smaller if the file is < 128 KB, but can also be larger if you manually configure it). So a ZFS block is even larger than a bcachefs "extent".

mastax 3y ago

Well yes, my point is that (counter to GP) ZFS doesn't combine together multiple blocks into a compression extent, rather it uses larger blocks by default.

someplaceguy 3y ago
ZFS's larger blocks you are referring to are the logical block size, which is the size unit for compression among other things. I don't know much about bcachefs, but as I understand it, a logical block in ZFS is equivalent to a bcachefs extent (in terms of compression, at least) and a ZFS physical block is equivalent to a (possibly empty) set of bcachefs blocks. As an example, in terms of actual on-disk storage, a 128 KB logical block in ZFS can be compressed down to (for example) a 3.5 KB "physical" block and it will only actually consume 3.5 KB of disk space (surprisingly, the block size of a ZFS physical block doesn't have to be a power of 2!). That said, if you have 4 KB-sector disks then you should probably use a physical block size granularity of 4 KB for your ZFS pool rather than 512 bytes. So, regardless of the file size, an on-disk ZFS block can actually occupy anywhere from 0 bytes up to 1 MB, with a granularity of up to 512 bytes, depending on how much it is compressed, what the physical block size granularity of the ZFS pool is and what you've selected as the recordsize property (i.e. the logical block size) for the corresponding filesystem in the pool.
- rincebrain 3y ago
  16M, not 1M.
  - someplaceguy 3y ago
    Thanks for the correction. The `zfsprops` man page should be updated to reflect that...
    - rincebrain 3y ago
      It has been. The default was to limit it to 1M in case there were weird edge cases with the larger sizes (16M is the largest it'll encode on disk without a format change, IIRC), with larger sizes behind a tunable, but after a few years of people who knew this twiddling it, the default in 2.2 will be that the tunable is set to 16M.
- 5e92cb50239222b 3y ago
  > if you have 4 KB-sector disks then you should probably use a physical block size granularity of 4 KB for your ZFS pool rather than 512 bytes According to Allan Jude (OpenZFS & FreeBSD developer), you should never use 512-byte recordsize even on an HDD with 512-byte sectors. Always start from 4 KiBs, probably even from 8. https://klarasystems.com/articles/tuning-recordsize-in-openzfs https://klarasystems.com/articles/tuning-recordsize-in-openz...
  - someplaceguy 3y ago
    > you should never use 512-byte recordsize even on an HDD with 512-byte sectors I think you meant to refer to the pool's sector size (i.e. "ashift" property) rather than the recordsize. I agree, but I wouldn't say "never", as that's too strong a word. It would be useful to use a 512-byte ZFS pool sector size even when the HDD uses 4K sectors if you care a lot about disk space efficiency but don't care at all about performance or HDD wear (for example, if you plan to use a ZFS pool almost exclusively read-only). That said, I would also recommend a 4K pool sector size in almost all cases, as HDD space is cheap.
  - rincebrain 3y ago
    I don't think that post is saying that. I think that post is warning you that it's immutable once done. If you want to be more flexible in the future and can't be sure you won't need to use 4kn/512e disks at some point, yes, use 4kn (or with all SSD storage it gets even messier). But using 512b can be a significant gain on space efficiency for some people.
- mastax 3y ago
  I understand all of that. None of that disagrees with what I have said. I think we're talking past each other. In a practical sense I agree the two filesystems achieve an essentially identical result through very similar methods, as you have said. I am making a point specifically about the details of the implementation logic of the two filesystems. Bcachefs (as I understand it) combines multiple smaller blocks into a larger extent. ZFS only has one raw record and its corresponding on-disk compressed record, whose size is rounded up to ashift.