5 ms·

Xfs ? Bcachefs ? Whatever you like because those features may not be implemented at the filesystem layer ?

do_not_redeem 2y ago
xfs doesn't have data checksumming. > Note: Unlike Btrfs and ZFS, the CRC32 checksum only applies to the metadata and not actual data. https://wiki.archlinux.org/title/XFS https://wiki.archlinux.org/title/XFS --- bcachefs isn't stable enough to daily drive. > Nobody sane uses bcachefs and expects it to be stable —Linus Torvalds (2024) https://lore.kernel.org/lkml/CAHk-%3Dwj1Oo9-g-yuwWuHQZU8v%3DVAsBceWCRLhWxy7_-QnSa1Ng@mail.gmail.com/ https://lore.kernel.org/lkml/CAHk-%3Dwj1Oo9-g-yuwWuHQZU8v%3D...
- JackSlateur 2y ago
  [flagged]
- koverstreet 2y ago
  Linus is not a filesystem guy
  - starspangled 2y ago
    You don't have to be to see bug reports, bug fix patches, or test it yourself, of course. "Filesystem guys" also tend to wear rose colored glasses when it comes to their filesystem, at times (ext2, xfs, btrfs, etc.)
    - koverstreet 2y ago
      Linus absolutely does jump in on VFS level bugs when necessary (and major respect for that; he doesn't rest on laurels and he's always got his priorities in the right place) - but there's only so much he can keep track of, and the complexity of a modern filesystem tends to dwarf other subsystems. The people at the top explicitly don't and can't keep track of everything, there's a lot of stuff (e.g. testing) that they leave to other people - and I do fault them for that a bit; we badly need to get a bit more organized on test infrastructure. And I wouldn't say that filesystem people in general wear rose colored glasses; I would categorize Dave Chinner and Ted T'so more in the hard nosed realistic category, and myself as well. I'd say it's just the btrfs folks who've had that fault in the past, and I think Josef has had more than enough experience at this point to learn that lesson.
      - starspangled 2y ago
        > Linus absolutely does jump in on VFS level bugs when necessary (and major respect for that; he doesn't rest on laurels and he's always got his priorities in the right place) - but there's only so much he can keep track of, and the complexity of a modern filesystem tends to dwarf other subsystems. The point is he doesn't have to understand details of the code to see bug reports and code churn and bug fix commits and have a reasonable idea of whether it's stable enough for end users. I would trust him to make that call more than a "filesystem guy", in fact. > The people at the top explicitly don't and can't keep track of everything, there's a lot of stuff (e.g. testing) that they leave to other people - and I do fault them for that a bit; we badly need to get a bit more organized on test infrastructure. Absolutely not on the top nodes. Testing has to be distributed and pushed down to end nodes where development happens or even below otherwise it does not scale. > And I wouldn't say that filesystem people in general wear rose colored glasses; Perhaps that's what you see through your rose colored glasses? (sorry, just a cheeky dig). > I would categorize Dave Chinner and Ted T'so more in the hard nosed realistic category, and myself as well. I'd say it's just the btrfs folks who've had that fault in the past, and I think Josef has had more than enough experience at this point to learn that lesson. Dave Chinner for example would insist the file-of-zeroes problem of XFS is really not a problem. Not because he was flat wrong or consciously being biased for XFS I'm sure, but because according to the filesystem design and the system call interface and the big customers they talked to at SGI, it was operating completely as per specification. I'm not singling out filesystem developers or any one person or even software development specifically. All complex projects need advocates and input from outside stakeholders (users, other software, etc) for this exact reason, is that those deep in the guts of it usually don't understand all perspectives.
        koverstreet 2y ago
        > The point is he doesn't have to understand details of the code to see bug reports and code churn and bug fix commits and have a reasonable idea of whether it's stable enough for end users. I would trust him to make that call more than a "filesystem guy", in fact. No, that's not enough, and I would not call that kind of slagging good communication to users. Seeing bugfixes go by doesn't tell you that much, and it definitely doesn't tell you which filesystem to recommend to users because other filesystems simply may not be fixing critical bugs. Based on (a great many) user reports that I've seen, I actually have every reason to believe that your data is much safer on bcachefs than btrfs. I'm not shouting about that while I still have hardening to do, and my goal isn't just to beat btrfs, it's to beat ext4 and xfs as well: but given what I see I have to view Linus's communications as irresponsible. > Absolutely not on the top nodes. Testing has to be distributed and pushed down to end nodes where development happens or even below otherwise it does not scale. No, our testing situation is crap, and we need leadership that says more than "not my problem". > Dave Chinner for example would insist the file-of-zeroes problem of XFS is really not a problem. Not because he was flat wrong or consciously being biased for XFS I'm sure, but because according to the filesystem design and the system call interface and the big customers they talked to at SGI, it was operating completely as per specification. Well, he had a point, and you don't want to be artificially injecting fsyncs because for applications that don't need them that gets really expensive. Fsync is really expensive, and it impacts the whole system. Now, it turned out there is a clever and more practical solution to this (which I stole from ext4), but you simply cannot expect any one person to know the perfect solution to every problem. By way of example, I was in an argument with Linus a month or so ago where he was talking about filesystems that "don't need fsck" (which is blatently impossible), and making "2GB should be enough for anyone" arguments. No one is right all the time, no one has all the answers - but if you go into a conversation assuming the domain experts aren't actually the experts, that's not a recipe for a productive conversation.
  - mort96 2y ago
    Bcachefs is literally labeled as experimental.
- mappu 2y ago
  You can get data checksumming for any filesystem with dm-integrity.
  - kasabali 2y ago
    It has its own journaling mode just to really keep its integrity. Some things are just better solved at the filesystem level.

xfs doesn't have data checksumming. > Note: Unlike Btrfs and ZFS, the CRC32 checksum only applies to the metadata and not actual data. https://wiki.archlinux.org/title/XFS https://wiki.archlinux.org/title/XFS --- bcachefs isn't stable enough to daily drive. > Nobody sane uses bcachefs and expects it to be stable —Linus Torvalds (2024) https://lore.kernel.org/lkml/CAHk-%3Dwj1Oo9-g-yuwWuHQZU8v%3DVAsBceWCRLhWxy7_-QnSa1Ng@mail.gmail.com/ https://lore.kernel.org/lkml/CAHk-%3Dwj1Oo9-g-yuwWuHQZU8v%3D...

JackSlateur 2y ago
[flagged]
koverstreet 2y ago
Linus is not a filesystem guy
- starspangled 2y ago
  You don't have to be to see bug reports, bug fix patches, or test it yourself, of course. "Filesystem guys" also tend to wear rose colored glasses when it comes to their filesystem, at times (ext2, xfs, btrfs, etc.)
  - koverstreet 2y ago
    Linus absolutely does jump in on VFS level bugs when necessary (and major respect for that; he doesn't rest on laurels and he's always got his priorities in the right place) - but there's only so much he can keep track of, and the complexity of a modern filesystem tends to dwarf other subsystems. The people at the top explicitly don't and can't keep track of everything, there's a lot of stuff (e.g. testing) that they leave to other people - and I do fault them for that a bit; we badly need to get a bit more organized on test infrastructure. And I wouldn't say that filesystem people in general wear rose colored glasses; I would categorize Dave Chinner and Ted T'so more in the hard nosed realistic category, and myself as well. I'd say it's just the btrfs folks who've had that fault in the past, and I think Josef has had more than enough experience at this point to learn that lesson.
    - starspangled 2y ago
      > Linus absolutely does jump in on VFS level bugs when necessary (and major respect for that; he doesn't rest on laurels and he's always got his priorities in the right place) - but there's only so much he can keep track of, and the complexity of a modern filesystem tends to dwarf other subsystems. The point is he doesn't have to understand details of the code to see bug reports and code churn and bug fix commits and have a reasonable idea of whether it's stable enough for end users. I would trust him to make that call more than a "filesystem guy", in fact. > The people at the top explicitly don't and can't keep track of everything, there's a lot of stuff (e.g. testing) that they leave to other people - and I do fault them for that a bit; we badly need to get a bit more organized on test infrastructure. Absolutely not on the top nodes. Testing has to be distributed and pushed down to end nodes where development happens or even below otherwise it does not scale. > And I wouldn't say that filesystem people in general wear rose colored glasses; Perhaps that's what you see through your rose colored glasses? (sorry, just a cheeky dig). > I would categorize Dave Chinner and Ted T'so more in the hard nosed realistic category, and myself as well. I'd say it's just the btrfs folks who've had that fault in the past, and I think Josef has had more than enough experience at this point to learn that lesson. Dave Chinner for example would insist the file-of-zeroes problem of XFS is really not a problem. Not because he was flat wrong or consciously being biased for XFS I'm sure, but because according to the filesystem design and the system call interface and the big customers they talked to at SGI, it was operating completely as per specification. I'm not singling out filesystem developers or any one person or even software development specifically. All complex projects need advocates and input from outside stakeholders (users, other software, etc) for this exact reason, is that those deep in the guts of it usually don't understand all perspectives.
      - koverstreet 2y ago
        > The point is he doesn't have to understand details of the code to see bug reports and code churn and bug fix commits and have a reasonable idea of whether it's stable enough for end users. I would trust him to make that call more than a "filesystem guy", in fact. No, that's not enough, and I would not call that kind of slagging good communication to users. Seeing bugfixes go by doesn't tell you that much, and it definitely doesn't tell you which filesystem to recommend to users because other filesystems simply may not be fixing critical bugs. Based on (a great many) user reports that I've seen, I actually have every reason to believe that your data is much safer on bcachefs than btrfs. I'm not shouting about that while I still have hardening to do, and my goal isn't just to beat btrfs, it's to beat ext4 and xfs as well: but given what I see I have to view Linus's communications as irresponsible. > Absolutely not on the top nodes. Testing has to be distributed and pushed down to end nodes where development happens or even below otherwise it does not scale. No, our testing situation is crap, and we need leadership that says more than "not my problem". > Dave Chinner for example would insist the file-of-zeroes problem of XFS is really not a problem. Not because he was flat wrong or consciously being biased for XFS I'm sure, but because according to the filesystem design and the system call interface and the big customers they talked to at SGI, it was operating completely as per specification. Well, he had a point, and you don't want to be artificially injecting fsyncs because for applications that don't need them that gets really expensive. Fsync is really expensive, and it impacts the whole system. Now, it turned out there is a clever and more practical solution to this (which I stole from ext4), but you simply cannot expect any one person to know the perfect solution to every problem. By way of example, I was in an argument with Linus a month or so ago where he was talking about filesystems that "don't need fsck" (which is blatently impossible), and making "2GB should be enough for anyone" arguments. No one is right all the time, no one has all the answers - but if you go into a conversation assuming the domain experts aren't actually the experts, that's not a recipe for a productive conversation.
- mort96 2y ago
  Bcachefs is literally labeled as experimental.
mappu 2y ago
You can get data checksumming for any filesystem with dm-integrity.
- kasabali 2y ago
  It has its own journaling mode just to really keep its integrity. Some things are just better solved at the filesystem level.