Announcement

Collapse
No announcement yet.

EXT4 Data Corruption Bug Hits Stable Linux Kernels

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • RealNC
    replied
    A lot of people seem to confuse "panic" with "being careful."

    Leave a comment:


  • Pallidus
    replied
    Originally posted by energyman View Post
    I mean, come on. This 'bug' is as harmless as it can be. You have to do immensly stupid stuff to get hit by it. It is so common that 2 people out of millions of systems hit it.

    and you not only posted a very 'dramatic' idiotic story - you are now advertising it.

    Shouldn't you.. you know... prepare an apology or something like that?

    drama = hits = attention = things get fixed faster

    Leave a comment:


  • energyman
    replied
    heyy Michael, not embarrased enough?

    I mean, come on. This 'bug' is as harmless as it can be. You have to do immensly stupid stuff to get hit by it. It is so common that 2 people out of millions of systems hit it.

    and you not only posted a very 'dramatic' idiotic story - you are now advertising it.

    Shouldn't you.. you know... prepare an apology or something like that?

    Leave a comment:


  • Pallidus
    replied
    I demand restitutions

    linuxes has corrupted all my pr0ns

    Leave a comment:


  • ArchLinux
    replied
    Originally posted by Dewitt501 View Post
    Great on 3.4.15 which got updated a few days ago -.-
    And another one ("-.-.-..-.-.-.-.-.-.-.-.-.-.-"). The fix is already there despite the fact that you would never encounter this corruption anyway.

    Leave a comment:


  • makomk
    replied
    Originally posted by Naib View Post
    phoronix snowballing via tabloid-based sensationalistic posting... say it isn't true
    If I'm reading the mailing list discussion correctly, it might actually be worse than Phoronix originally reported - the filesystem corruption with esoteric mount options was a symptom of a more subtle silent filesystem corruption bug that affects all users (and possibly older kernel versions than previously suspected).

    Leave a comment:


  • Dewitt501
    replied
    Great on 3.4.15 which got updated a few days ago -.-

    Leave a comment:


  • ArchLinux
    replied
    Originally posted by ulenrich View Post
    It was a very,very special and unreasonable setup which triggerd the data loss for just two people.
    Sure. Not condemning him either. He's the reason udev stayed in such a good state for such a long time and that Linus actually _can_ focus on the rc kernels. Plus he's awesome.

    And I don't give a sh*t, if there's a sporadically triggered corruption here or an exceptionally occuring kernel panic there.

    That's the price you pay when dealing with such huge and crucial components and it's not something that in the end you really can avoid. It's the people like darkbasic, Lemonzest, frantaylor, etc. who don't understand or think about it.

    Their heads explode immediately when seeing things like this and they have to assume it's something that occurs every single time they move their mouse for more than two pixels.

    Leave a comment:


  • Naib
    replied
    phoronix snowballing via tabloid-based sensationalistic posting... say it isn't true

    Leave a comment:


  • NullNix
    replied
    Originally posted by ulenrich View Post
    It was a very,very special and unreasonable setup which triggerd the data loss for just two people.
    I resemble that remark. It wasn't an 'unreasonable' configuration per se, since the documentation doesn't actually mention that journal_async_commit is experimental. Nowadays it mentions that it enables journal_checksum, but it doesn't mention that that option is experimental let alone dangerous, and years back when I set up the /etc/fstab on the failing machine journal_checksum had never caused anyone problems in practice (this changed a couple of years later). And it does speed things up a good bit on metadata-heavy workloads, which I cared about.

    And then I used that configuration for three and a half years with not a single tiny problem. Sorry, I don't generally go back to three-and-a-half year old working system configurations and wonder if perhaps they are too dangerous and should be changed! -- not until they actually cause problems, that is.

    Now if you use nobarrier without battery-backed hardware RAID or something equally high-end with independent power (like a SAN), you are indeed doing something unreasonable, verging on suicidal. But battery-backed hardware RAID isn't actually that expensive anymore, and isn't that rare: it added less than ?100 to the cost of this machine when I bought it (and performance-wise, it flies!).

    And, hey, even if it was unreasonable, part of the reason why I run with strange options is so that I can report bugs in them

    What was probably unreasonable was splashing a conversation/debugging-in-progress all over the media. I still haven't found all the places this got published, almost always hyped-up beyond any reasonable degree, and with the exception of LWN (where I posted a 'hey, hold off upgrading for now' comment) *everyone* got it wrong. Oh well. (As far as I can tell, Phoronix was first, and was probably the source from which this fountain of inaccuracy sprang.)

    Leave a comment:

Working...
X