Hacker News Reader

Comment by cjbprime | Hacker News Reader

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.)

View on HN

> 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

Ah, okay. I think the title is misleading and should be changed.

Is it (and the url) ok now?

> (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.

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

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.

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

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.

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."

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.

I think JFS still has that problem, if Wikipedia is accurate.

Reply on news.ycombinator.com