4 ms·

As far as I can see, the "critical" label here is coming from a Debian user submitting a Debian bug report, not from the Debian kernel team or upstream kernel m

As far as I can see, the "critical" label here is coming from a Debian user submitting a Debian bug report, not from the Debian kernel team or upstream kernel maintainers. I think HN submissions should have some standards for stories that will create the appearance of "there is a critical problem with software X that lots of people use, and everyone should panic and upgrade" announcements. Having the authors of software X involved in the announcement seems like it would be a good place to start. (I'm not saying that Josh is mistaken about having been hit by this bug, or was involved in the decision to submit this to HN.)

railsisfails 11y ago
Data loss is not critical? Wow, remind us not to trust your firm with our data.
- cjbprime 11y ago
  Every filesystem contains edge case bugs that lose data. The answer to whether everyone reading this story should go upgrade their kernel right now to avoid this one depends on factors like how probable it is that users will hit this one, and how risky the fix is. The project maintainers are in the best position to make that call.
  - feld 11y ago
    Delayed extents is probably a normal thing that happens in daily I/O operations. The possibility of it not actually hitting the platters permanently is a scary scenario. "A single extent in ext4 can map up to 128 MiB of contiguous space with a 4 KiB block size."
    - StillBored 11y ago
      The whole bug sounds similar to a problem we had on XFS back in the 2.6.16 time frame. Certain operations were delayed for hours meaning that it was possible for renames/writes not to hit the platter if the machine experienced power loss instead of a clean shutdown, even if sync's were performed.
      - feld 11y ago
        I think JFS still has that problem, if Wikipedia is accurate.
deleted 11y ago
[deleted]
dang 11y ago
> HN submissions should have some standards for stories that will create the appearance HN has such a standard: the guidelines ask for titles not to be misleading or linkbait. (Not an opinion on the current bug.) https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
- cjbprime 11y ago
  Ah, okay. I think the title is misleading and should be changed.
  - dang 11y ago
    Is it (and the url) ok now?
kasabali 11y ago
You're definitely right. "critical" in this context means it has a critical severity as a Debian bug, it doesn't mean everybody must stop what they're doing right now and patch their kernel. If I interpreted the commit message correctly, this bug is not a new thing at all and it has been there for years, but it has been noticed only lately, which means we're no better applying the fix now than waiting until distribution packages ship it.
JoshTriplett 11y ago
> (I'm not saying that Josh is mistaken about having been hit by this bug, or was involved in the decision to submit this to HN.) I was not involved, and it's sounding like this is a different bug than the one I got hit by. This bug still qualifies as "critical" in a Debian bug-reporting severity sense ("causes serious data loss"). I don't know what the original title was though.
- cjbprime 11y ago
  Ah, this story originally linked to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=785672 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=785672 and shared its title ("Critical ext4 data corruption bug").

railsisfails 11y ago

Data loss is not critical? Wow, remind us not to trust your firm with our data.

cjbprime 11y ago
Every filesystem contains edge case bugs that lose data. The answer to whether everyone reading this story should go upgrade their kernel right now to avoid this one depends on factors like how probable it is that users will hit this one, and how risky the fix is. The project maintainers are in the best position to make that call.
- feld 11y ago
  Delayed extents is probably a normal thing that happens in daily I/O operations. The possibility of it not actually hitting the platters permanently is a scary scenario. "A single extent in ext4 can map up to 128 MiB of contiguous space with a 4 KiB block size."
  - StillBored 11y ago
    The whole bug sounds similar to a problem we had on XFS back in the 2.6.16 time frame. Certain operations were delayed for hours meaning that it was possible for renames/writes not to hit the platter if the machine experienced power loss instead of a clean shutdown, even if sync's were performed.
    - feld 11y ago
      I think JFS still has that problem, if Wikipedia is accurate.

deleted 11y ago

[deleted]

dang 11y ago

> HN submissions should have some standards for stories that will create the appearance HN has such a standard: the guidelines ask for titles not to be misleading or linkbait. (Not an opinion on the current bug.) https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html

cjbprime 11y ago
Ah, okay. I think the title is misleading and should be changed.
- dang 11y ago
  Is it (and the url) ok now?

kasabali 11y ago

You're definitely right. "critical" in this context means it has a critical severity as a Debian bug, it doesn't mean everybody must stop what they're doing right now and patch their kernel. If I interpreted the commit message correctly, this bug is not a new thing at all and it has been there for years, but it has been noticed only lately, which means we're no better applying the fix now than waiting until distribution packages ship it.

JoshTriplett 11y ago

> (I'm not saying that Josh is mistaken about having been hit by this bug, or was involved in the decision to submit this to HN.) I was not involved, and it's sounding like this is a different bug than the one I got hit by. This bug still qualifies as "critical" in a Debian bug-reporting severity sense ("causes serious data loss"). I don't know what the original title was though.

cjbprime 11y ago
Ah, this story originally linked to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=785672 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=785672 and shared its title ("Critical ext4 data corruption bug").