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

21–30 of 138 posts

Re: Linux: Ext4 data corruption in 6.1.64-1

#21

Post by piperswe »

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.

The way I'd interpret it is that it's non-serious if fsck can repair it. Not sure if that's accurate though, just the way it sounds to me.

Re: Linux: Ext4 data corruption in 6.1.64-1

#22

Post by Blikkentrekker »

Lt_Riza_Hawkeye wrote: post #19
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.

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.

Re: Linux: Ext4 data corruption in 6.1.64-1

#23

Post by asdfgasdfh »

Lt_Riza_Hawkeye wrote: post #19
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.

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

[dead]

Re: Linux: Ext4 data corruption in 6.1.64-1

#24

Post by orhmeh09 »

arglebargle123 wrote: post #15
userbinator wrote: post #4

Severity: grave I'm not sure if that's a standard value, but it made me chuckle a little.

It would have been really funny if they reported that one as: Severity: `

This might start executing a subshell in some ancient script. Avoid!

Re: Linux: Ext4 data corruption in 6.1.64-1

#26

Post by baz00 »

GauntletWizard wrote: post #20
uxp8u61q wrote: post #11

Earlier quoted context omitted.

This isn't a sports tournament, nobody is cheering or bashing "teams". If ZFS has bugs and caveats, they should be called out. Same for ext4.

[flagged]

Well said. Twisted partisanism.

I’m the middle ground. It all sucks in one way or another but we’re generally trying to our best.

Re: Linux: Ext4 data corruption in 6.1.64-1

#27

Post by esbeeb »

megous wrote: post #9
esbeeb wrote: post #7

In Debian bookworm: "sudo systemctl stop unattended-upgrades.service" ... wasn't able to prevent unattended-upgrades from going on ahead and just upgrading (to this problematic kernel) anyway. Unintuitively, the "right" way to disable unattended-upgrades is: "sudo dpkg-reconfigure unattended-upgrades" ...and choose "No" when asked.

Most likley because you stopped the wrong service. You should have stopped the relevant timer service, not the service that the timer starts.

Can you give example code to stop that timer?

Re: Linux: Ext4 data corruption in 6.1.64-1

#28

Post by uselpa »

Lt_Riza_Hawkeye wrote: post #19
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.

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

Are you sure about that (genuine question)? The linked discussion involves a Suse engineer and a request to the kernel maintainer directly, not to a Debian packager-

Re: Linux: Ext4 data corruption in 6.1.64-1

#29

Post by uselpa »

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…

I understand your reasoning, but running a popular « stable » distro in a popular configuration will help detect bugs much faster. I’m not sure this would be the case for the very latest kernel.

Re: Linux: Ext4 data corruption in 6.1.64-1

#30

Post by viraptor »

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.

If you're trying to be padantic and missing forest for the trees... Sure.
Post reply on HN