3 ms·

And the biggest highlight that wasn't mentioned anywhere in the release notes for some reason… (drum roll) 64-bit inodes!!

rsync 8y ago
I assume that is 64-bit inodes for UFS2 ? I would be concerned about the ability to fsck a UFS2 filesystem with enough inodes in it to require 64-bit inodes... As late as 2010/2011 fsck would fail to allocate enough memory to successfully repair a filesystem with <200M inodes ... I have it on good authority (the author of UFS) that there is no reason to use UFS instead of ZFS unless you are severely memory constrained. Perhaps I misunderstand the new feature you are highlighting ?
- markjdb 8y ago
  No, various kernel entry points have been modified to be able to handle 64-bit inode numbers. UFS itself still uses 32-bit inode numbers.
- loeg 8y ago
  > I assume that is 64-bit inodes for UFS2 ? No, it's a kernel ABI change such that all of the stat(2), getdirents(2), etc, ABIs take and pass a 64-bit value instead of a 32-bit one. This enables: (1) 64-bit NFS fileservers (2) Direct-pointer "inode" numbers for FUSE filesystems or cd9660/UDF (3) Probably other uses I'm forgetting Additionally, other ABI enhancements were committed as part of the ino64 work: https://svnweb.freebsd.org/base?view=revision&revision=318736 https://svnweb.freebsd.org/base?view=revision&revision=31873... In particular, I'd point you at d_namlen bumping to 16 bits, MNAMELEN to 1024 bytes (from the anemic 88), and nlink_t from 16 bits to 64 bits. None of these are necessarily used in any particular filesystem, yet, but the generic ABI support is now present. > there is no reason to use UFS instead of ZFS unless you are severely memory constrained. Eh, that's an oversimplification. Here a few reasons: (1) Addressing the "severely" in the above: ZFS memory usage is astronomical, and it is sort of designed to be a filer — it thinks all of the RAM is for its use. It eats all of memory for cache (which is fine, that's what any filesystem cache does) but is slow to release memory under pressure. Also, it requires significantly larger caches than most other filesystems to perform acceptably. (2) Database and similar workload performance — ZFS is a CoW filesystem. That has all of the same problems for databases and similar workloads as any other CoW filesystem. Namely, overwritten blocks will be reallocated to a completely different part of disk and you lose any physical contiguity you might have had. This matters on spinning media and is a factor in why ZFS requires large caches to perform acceptably. (3) Journaling. ZFS intent log essentially duplicates the number of bytes written to media. This definitely has benefits (powerfail consistency) but also is an obvious cost. (Also, that same UFS author continues to work on adding UFS features, because Netflix pays him to. Netflix isn't a charity; they've pretty clearly determined that UFS provides better value to them than ZFS. And they have a phenomenal engineering organization, so I'd tend to trust them on that. YMMV, of course; unless you run a CDN, your workload likely isn't anything like Netflix's.)

rsync 8y ago

I assume that is 64-bit inodes for UFS2 ? I would be concerned about the ability to fsck a UFS2 filesystem with enough inodes in it to require 64-bit inodes... As late as 2010/2011 fsck would fail to allocate enough memory to successfully repair a filesystem with <200M inodes ... I have it on good authority (the author of UFS) that there is no reason to use UFS instead of ZFS unless you are severely memory constrained. Perhaps I misunderstand the new feature you are highlighting ?

markjdb 8y ago
No, various kernel entry points have been modified to be able to handle 64-bit inode numbers. UFS itself still uses 32-bit inode numbers.
loeg 8y ago
> I assume that is 64-bit inodes for UFS2 ? No, it's a kernel ABI change such that all of the stat(2), getdirents(2), etc, ABIs take and pass a 64-bit value instead of a 32-bit one. This enables: (1) 64-bit NFS fileservers (2) Direct-pointer "inode" numbers for FUSE filesystems or cd9660/UDF (3) Probably other uses I'm forgetting Additionally, other ABI enhancements were committed as part of the ino64 work: https://svnweb.freebsd.org/base?view=revision&revision=318736 https://svnweb.freebsd.org/base?view=revision&revision=31873... In particular, I'd point you at d_namlen bumping to 16 bits, MNAMELEN to 1024 bytes (from the anemic 88), and nlink_t from 16 bits to 64 bits. None of these are necessarily used in any particular filesystem, yet, but the generic ABI support is now present. > there is no reason to use UFS instead of ZFS unless you are severely memory constrained. Eh, that's an oversimplification. Here a few reasons: (1) Addressing the "severely" in the above: ZFS memory usage is astronomical, and it is sort of designed to be a filer — it thinks all of the RAM is for its use. It eats all of memory for cache (which is fine, that's what any filesystem cache does) but is slow to release memory under pressure. Also, it requires significantly larger caches than most other filesystems to perform acceptably. (2) Database and similar workload performance — ZFS is a CoW filesystem. That has all of the same problems for databases and similar workloads as any other CoW filesystem. Namely, overwritten blocks will be reallocated to a completely different part of disk and you lose any physical contiguity you might have had. This matters on spinning media and is a factor in why ZFS requires large caches to perform acceptably. (3) Journaling. ZFS intent log essentially duplicates the number of bytes written to media. This definitely has benefits (powerfail consistency) but also is an obvious cost. (Also, that same UFS author continues to work on adding UFS features, because Netflix pays him to. Netflix isn't a charity; they've pretty clearly determined that UFS provides better value to them than ZFS. And they have a phenomenal engineering organization, so I'd tend to trust them on that. YMMV, of course; unless you run a CDN, your workload likely isn't anything like Netflix's.)