4 ms·

The proliferation of Linux filesystems such as ext4, XFS, ZFS, btrfs, reiserfs, JFS, JFFS, bcachefs, etc. If any of those filesystems were truly adequate there

The proliferation of Linux filesystems such as ext4, XFS, ZFS, btrfs, reiserfs, JFS, JFFS, bcachefs, etc. If any of those filesystems were truly adequate there wouldn't have to be so many. First of all ZFS is not a “linux” filesystem. Second, available choice of filesystem is a strange thing to use as justification that previously existing filesystems are “inadequate”. By what criteria are you establishing adequacy? Success of technologies is often not dependent solely upon their technical excellence but on a variety of factors that may have nothing to do with the technology itself. (Betamax vs VHS, etc.)

PaulHoule 7y ago
In theory people would pick the filesystem which is ideal for their application. In practice it is a lot of work to research the choices, and there's a high risk that you'll discover something wrong with your filesystem only when it is too late. It's one thing to pontificate for and against particular file systems, it's another to use one for years, terabytes, etc. ZFS might scrub your data to protect against bitrot, but I remember reading harrowing tales from ZFS enthusiasts who were recovering (or not recovering) from wrecks every week but seemed to think it was a lot of fun, or conferred them status, or was otherwise a good thing. I stuck with ext4 for a long time before finally building a server that uses ZFS/HDD for media storage (e.g. not a lot of random access) I remember the time when a project I was involved with chose reiserfs because they thought it was "better" and then they were shocked when once in a while the system crash and we found that a file that had just been created was full of junk. That's a trade-off they made, they decided it was important to journal filesystem metadata (the length of the file is right) but not to protect the content. If they read the docs, really thought about it, then understood it, they would have known, but they didn't. This book points out that in cases where there is too much competition, you can switch all you like between flawed alternatives, but have no way to communicate what you really want: https://en.wikipedia.org/wiki/Exit,_Voice,_and_Loyalty https://en.wikipedia.org/wiki/Exit,_Voice,_and_Loyalty And when it comes to the "Filesystem API" probably anybody who has special needs for filesystem performance would find that a different API than the standard filesystem API would be a boon.
- throw0101a 7y ago
  > In practice it is a lot of work to research the choices ... More is not always better: * https://en.wikipedia.org/wiki/The_Paradox_of_Choice https://en.wikipedia.org/wiki/The_Paradox_of_Choice
- binarycrusader 7y ago
  I don't disagree with the general premise that a single filesystem might not be applicable or appropriate to all cases or that existing filesystems apis are generally deficient. My primary issue was with the two specific assertions I addressed, one of a given filesystem's origins and that of choice should being used as a proxy for evaluation of adequacy. As for ZFS enthusiasts "recovering from wrecks every week", I suspect you're specifically referring to ZFS on Linux or one of the BSDs -- which is not the same as ZFS when used in its original environment -- Solaris.
  - PaulHoule 7y ago
    No, it was on Solaris back when ZFS was new. It seemed like these people enjoyed having wrecks, like the Plebe who enjoyed getting hazed in https://www.amazon.com/Sense-Honor-Bluejacket-Books/dp/1557509174 https://www.amazon.com/Sense-Honor-Bluejacket-Books/dp/15575...
    - seized 7y ago
      So because a file system had issues 20 years ago when it was new.... Do you still drive a car with a carburetor and drum brakes? ZFS is now incredibly stable and durable, with the exception of some of the early non production ZFS on Linux work that is now fixed (and was specifically billed as non prod use). It has seen me through issues that other file systems would have failed on, including drive failures, hard shutdowns, a bad RAM module, SAS card being fried by a CPU water cooler, etc. Years and terabytes just on my systems, zero issues. In fact one of the tests that Sun did back in the day was to write huge amounts of data to a NAS and pull the power cord mid writing. Then repeated that a few thousand times. It never corrupted the file system.
    - 7y ago

PaulHoule 7y ago

In theory people would pick the filesystem which is ideal for their application. In practice it is a lot of work to research the choices, and there's a high risk that you'll discover something wrong with your filesystem only when it is too late. It's one thing to pontificate for and against particular file systems, it's another to use one for years, terabytes, etc. ZFS might scrub your data to protect against bitrot, but I remember reading harrowing tales from ZFS enthusiasts who were recovering (or not recovering) from wrecks every week but seemed to think it was a lot of fun, or conferred them status, or was otherwise a good thing. I stuck with ext4 for a long time before finally building a server that uses ZFS/HDD for media storage (e.g. not a lot of random access) I remember the time when a project I was involved with chose reiserfs because they thought it was "better" and then they were shocked when once in a while the system crash and we found that a file that had just been created was full of junk. That's a trade-off they made, they decided it was important to journal filesystem metadata (the length of the file is right) but not to protect the content. If they read the docs, really thought about it, then understood it, they would have known, but they didn't. This book points out that in cases where there is too much competition, you can switch all you like between flawed alternatives, but have no way to communicate what you really want: https://en.wikipedia.org/wiki/Exit,_Voice,_and_Loyalty https://en.wikipedia.org/wiki/Exit,_Voice,_and_Loyalty And when it comes to the "Filesystem API" probably anybody who has special needs for filesystem performance would find that a different API than the standard filesystem API would be a boon.

throw0101a 7y ago
> In practice it is a lot of work to research the choices ... More is not always better: * https://en.wikipedia.org/wiki/The_Paradox_of_Choice https://en.wikipedia.org/wiki/The_Paradox_of_Choice
binarycrusader 7y ago
I don't disagree with the general premise that a single filesystem might not be applicable or appropriate to all cases or that existing filesystems apis are generally deficient. My primary issue was with the two specific assertions I addressed, one of a given filesystem's origins and that of choice should being used as a proxy for evaluation of adequacy. As for ZFS enthusiasts "recovering from wrecks every week", I suspect you're specifically referring to ZFS on Linux or one of the BSDs -- which is not the same as ZFS when used in its original environment -- Solaris.
- PaulHoule 7y ago
  No, it was on Solaris back when ZFS was new. It seemed like these people enjoyed having wrecks, like the Plebe who enjoyed getting hazed in https://www.amazon.com/Sense-Honor-Bluejacket-Books/dp/1557509174 https://www.amazon.com/Sense-Honor-Bluejacket-Books/dp/15575...
  - seized 7y ago
    So because a file system had issues 20 years ago when it was new.... Do you still drive a car with a carburetor and drum brakes? ZFS is now incredibly stable and durable, with the exception of some of the early non production ZFS on Linux work that is now fixed (and was specifically billed as non prod use). It has seen me through issues that other file systems would have failed on, including drive failures, hard shutdowns, a bad RAM module, SAS card being fried by a CPU water cooler, etc. Years and terabytes just on my systems, zero issues. In fact one of the tests that Sun did back in the day was to write huge amounts of data to a NAS and pull the power cord mid writing. Then repeated that a few thousand times. It never corrupted the file system.
  - 7y ago