Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Linux: Ext4 data corruption in 6.1.64-1

bugs.debian.org

Post reply on HN
Print view View original

81–90 of 138 posts

Re: Linux: Ext4 data corruption in 6.1.64-1

#81

Post by keep_reading »

Blikkentrekker wrote: post #22
Lt_Riza_Hawkeye wrote: post #19

Earlier quoted context omitted.

The problem here was Debian's distribution process. Any distro compiling linux from the releases on kernel.org was not affected.

So this is another bug introduced by Debian itself by patching things? I remember that there was a fairly severe one which was caused by patching OpenSSL I think? But I remember the change they made being fairly weird and no one understood why but it was easy to see that it would introduce a vulnerability.

I remember when they made 2 CVEs back to back in Apache by incorrect back porting of changes

Re: Linux: Ext4 data corruption in 6.1.64-1

#82

Post by keep_reading »

megous wrote: post #8
upon_drumhead wrote: post #5

Earlier quoted context omitted.

Yeah, all the threads full of folks bashing on ZFS because their trusty ext won’t corrupt data should be eating crow right about now, but I’m sure they’ll hop in and explain why this bug is different.

It's not an extfs bug, it's a "stable kernel" process bug. Linux master branch/mainline was never affected by this bug. Someone cherry-picked a wrong patch into stable without realizing the consequences, and it was caught too late. Stable process is cherry pincking thousands to tens of thousands of patches from the current master kernel branch into years old kernel branches, spraying tens of thousands of emails at or…

Nobody ships vanilla kernels. Sure the reference implementation was unaffected but users never experience vanilla Linux kernels

Re: Linux: Ext4 data corruption in 6.1.64-1

#83

Post by LoganDark »

userbinator wrote: post #18
viraptor wrote: post #17

Earlier quoted context omitted.

I believe the Debian policy for reports says that for corruption you can recover from. Serious data loss would be losing your metadata and not being able to figure out where any of the files are, or corrupting all copies of the disk encryption key.

I think "corruption you can recover from" seems far too vague; you can recover from any corruption with backups.

Sure, and you can recover from any hardware failure with a separate computer. In fact, you can recover from death simply by cloning yourself. What's the issue?

The issue is that some people don't have the time, money, and/or willpower to invest in backups. Some people only have one volume, or one copy of each volume at least, and need to recover their data using only that one volume if something gets corrupted. That's what "corruption you can recover from" means. Using a backup is not recovering from corruption; it's replacing the corruption with the pre-corrupted data. Recovering from corruption involves actually transforming the corrupted data back into non-corrupted data.

Re: Linux: Ext4 data corruption in 6.1.64-1

#84

Post by Narishma »

jacooper wrote: post #76

It seems they have frozen the roll out of 6.1.0-14 too? Did they just freeze all Kernel Updates using `HTTP 403 - broken package ` as a response?

That version is the one (or one of the ones) affected. I'm guessing that's why they froze it, though why they didn't replace it with a newer one, or even the old safe version I'm not sure.

Re: Linux: Ext4 data corruption in 6.1.64-1

#85

Post by HankB99 »

Kunix wrote: post #50

Have any guidelines been posted somewhere for systems already updated to linux-image-amd64 6.1.64-1?

My desktop and laptop are both root on ZFS so I dodged this bug. (Actually I saw the press on this before upgrading anyway so I'm holding off until I see a fix released.)

Re: Linux: Ext4 data corruption in 6.1.64-1

#86

Post by LoganDark »

Roark66 wrote: post #40
Grimburger wrote: post #38

Earlier quoted context omitted.

Most data is recoverable albeit slow to do. It takes some very bad conditions or intentional actions to make data recovery impossible. Current high level standards for military/diplomatic data sanatisation are complete physical destruction of hard disks. Even linux tools like shred have given up saying they can actually delete data from disks due to how SSD's work these days.

SSDs are not magic. For shredding to be impossible the drives would have to have hidden capacity (and a lot of it, more than 1%). People often say, write levelling makes overwriting useless, but what if you overwrite the entire disk? How would you recover after something like this? Of course providing something like 10% of hidden extra capacity would extend the life of the drive significantly, but are manufacturers r…

SSDs don't cycle blocks based on how much you've written. You can write over the entire reported capacity of a drive 100 times and there's still the chance, however small, that your encryption key and some encrypted data are still sitting around on some chip. You just can't guarantee that it's gone. For all you know, the controller has marked them as bad and isn't going to reuse them, even though there's still recoverable data on them. Since there's no way to reach them through the drive interface, there's also no way to erase them. But if someone opened up the drive and pulled the chips, there they would be.

Re: Linux: Ext4 data corruption in 6.1.64-1

#88

Post by frankjr »

Here's my understanding so far:

In the upstream Linux kernel there were two fixes posted months from each other, one for direct io [0] and the other one for ext4 [1]. The ext4 one was marked for backport to stable (CC: stable@vger.kernel.org), the other was not. The problem is that these commits depend on each other for things to work properly. If you have both, you're fine. If you have only the backported one, you have a problem.

Which versions are affected? We know for sure that 6.1.64 is affected, 6.1.55 is not (because it doesn't have the commit). As of right now, 6.1.64 is still marked as "stable" in Debian [2] but if you actually try to install it from the official mirrors (deb.debian.org), you will get error 403. The fix is included in version 6.1.66 which will soon be available.

The issue seems to be only highlighted in the context of Debian but it is not specific to it. The issue is/was in the official upstream release.

[0] https://github.com/torvalds/linux/commit/936e114a245b6e38e0d...

[1] https://github.com/torvalds/linux/commit/91562895f8030cb9a04...

[2] https://packages.debian.org/source/stable/linux

Re: Linux: Ext4 data corruption in 6.1.64-1

#90

Post by 404mm »

GauntletWizard wrote: post #3

As someone who is heavily dependent on zfs, this is a little bit of reassurance. Sad that data corruption exists in any file system that is shipped too many people, but reassuring that it happens to the most stable and least "interesting" in the newness sense file systems. ZFS's own recent file system corruption issue is in roughly the same category of edge case, but accessible to reasonable if niche workloads.

You’re forgetting the btrfs folks.

— someone who lost data due to btrfs bug

Post reply on HN