5 ms·

No coder should ever, ever be shocked that broken code mostly kind of seems to work, especially if you don't notice things like file corruption because you're n

No coder should ever, ever be shocked that broken code mostly kind of seems to work, especially if you don't notice things like file corruption because you're not looking, or memory corruption that doesn't happen to matter at the moment. A lot of the failures and bad code are in the unexpected path.

edoceo 2y ago
When this box does have issue (rare), it's right after I've done some upgrades to packages that the distribution has told me aren't ready. I know I'm standing on the edge (of glory!). Also, I use ext4 since like forever, ext3 before that and have never had issues. To be clear, my point is that these open source devs (I'm one too) are very careful to not regress. I think the software quality is very high.
- foobiekr 2y ago
  Your experience is selection bias. And if you never had issues with ext3fs, I assure you it's because you never checked.
  - edoceo 2y ago
    You've lost context and appear to be going after a weak interpretation with the implication I don't know how to sysadmin. The context was the sweeping generalisation that Linux devs and that they don't care about regressions, see up thread by @imiric. In that context I've not had regressions. More explicitly, for this narrower context, I've not had regression bugs in ext3/ext4. I'm not making a claim that I've not had never had ANY issues or never have to fsck my drives; nor am I making claims that nothing has ever appeared in 'lost+found', nor am I claiming that ext3/ext4 are perfect. Nor that Linux is perfect. Just claiming that the software quality in the Linux ecosystem is very high. I'd say better than many closed-source solutions -- which couldn't be proved anyway. I've only been at this since 1994 and still have a lot to learn. However, I don't learn much from the "you're wrong and not good" type of conversation.
    - foobiekr 2y ago
      I think you’re missing the point. Unless you were actually measuring the content of your file system with a reasonable quality hash function, you likely had actual data corruption that Fsck will never see. Fsck can’t check data on ext*. Unless you were routinely running mtree or something similar, you’d honestly have no idea. My point here is that software can appear to be fine when it’s actually shit because most people won’t notice any kind of corner case. All you’re saying is that you’ve very likely missed the corner cases.
      - edoceo 2y ago
        Cool
- ryao 2y ago
  When I used ext4, I had unexplainable ccache corruption about once per year when compiling updates for my Gentoo Linux machines. Since switching to ZFS about 12 years ago, ccache has not become corrupted once.
ryao 2y ago
I use ZFS to protect against file corruption and ECC RAM to protect against memory corruption. The combination works well. The combination is not perfect unfortunately. The other day, I had a CPU cache parity check failure hang vim when I was trying to close it. I had to reboot to get rid of the hung kernel thread. It would be really nice if all CPU cache levels had full ECC protection, but only some of them do.

edoceo 2y ago

When this box does have issue (rare), it's right after I've done some upgrades to packages that the distribution has told me aren't ready. I know I'm standing on the edge (of glory!). Also, I use ext4 since like forever, ext3 before that and have never had issues. To be clear, my point is that these open source devs (I'm one too) are very careful to not regress. I think the software quality is very high.

foobiekr 2y ago
Your experience is selection bias. And if you never had issues with ext3fs, I assure you it's because you never checked.
- edoceo 2y ago
  You've lost context and appear to be going after a weak interpretation with the implication I don't know how to sysadmin. The context was the sweeping generalisation that Linux devs and that they don't care about regressions, see up thread by @imiric. In that context I've not had regressions. More explicitly, for this narrower context, I've not had regression bugs in ext3/ext4. I'm not making a claim that I've not had never had ANY issues or never have to fsck my drives; nor am I making claims that nothing has ever appeared in 'lost+found', nor am I claiming that ext3/ext4 are perfect. Nor that Linux is perfect. Just claiming that the software quality in the Linux ecosystem is very high. I'd say better than many closed-source solutions -- which couldn't be proved anyway. I've only been at this since 1994 and still have a lot to learn. However, I don't learn much from the "you're wrong and not good" type of conversation.
  - foobiekr 2y ago
    I think you’re missing the point. Unless you were actually measuring the content of your file system with a reasonable quality hash function, you likely had actual data corruption that Fsck will never see. Fsck can’t check data on ext*. Unless you were routinely running mtree or something similar, you’d honestly have no idea. My point here is that software can appear to be fine when it’s actually shit because most people won’t notice any kind of corner case. All you’re saying is that you’ve very likely missed the corner cases.
    - edoceo 2y ago
      Cool
ryao 2y ago
When I used ext4, I had unexplainable ccache corruption about once per year when compiling updates for my Gentoo Linux machines. Since switching to ZFS about 12 years ago, ccache has not become corrupted once.

ryao 2y ago

I use ZFS to protect against file corruption and ECC RAM to protect against memory corruption. The combination works well. The combination is not perfect unfortunately. The other day, I had a CPU cache parity check failure hang vim when I was trying to close it. I had to reboot to get rid of the hung kernel thread. It would be really nice if all CPU cache levels had full ECC protection, but only some of them do.