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

31–40 of 138 posts

Re: Linux: Ext4 data corruption in 6.1.64-1

#31

Post by burtness »

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.

This is a misreading of the bug. It is from upstream stable kernels before 6.5 that include commit 91562895f803 but not 936e114a245b6[1].

In this case Debian's current process is good - it's kernels track kernel.org stable releases. This debian bug is responsibly flagging "for visibility" that a serious bug has been discussed and fixed upstream.

[1] https://lore.kernel.org/stable/20231205122122.dfhhoaswsfscuh...

Re: Linux: Ext4 data corruption in 6.1.64-1

#32

Post by peppermint_gum »

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.

This is not accurate. As you can see in the changelogs, the problematic commit made it to 6.1.64 and the fix was merged in 6.1.66:

"properly sync file size update after O_SYNC direct IO": https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.1.6...

"update ki_pos a little later in iomap_dio_complete": https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.1.6...

This post explains the relationship between the two commits: https://lore.kernel.org/stable/20231205122122.dfhhoaswsfscuh...

Re: Linux: Ext4 data corruption in 6.1.64-1

#33

Post by burtness »

uselpa wrote: post #28
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.

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-

No, its an upstream bug being discussed in the debian bug tracker

Re: Linux: Ext4 data corruption in 6.1.64-1

#35

Post by Timber-6539 »

esbeeb wrote: post #27
megous wrote: post #9

Earlier quoted context omitted.

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?

Usually, it's the same service name but with .timer at the end instead of .service.

Re: Linux: Ext4 data corruption in 6.1.64-1

#36

Post by KAMSPioneer »

esbeeb wrote: post #27
megous wrote: post #9

Earlier quoted context omitted.

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?

It's the same, but you disable the timer instead of the service. `sudo systemctl stop unattended-upgrades.timer`

Re: Linux: Ext4 data corruption in 6.1.64-1

#37

Post by cpach »

mgdhar wrote: post #13

Curious why it doesn’t happen on GNU? Context: This is seen in the following environments: > > > * dragonboard-845c > > > * juno-64k_page_size > > > * qemu-arm64 > > > * qemu-armv7 > > > * qemu-i386 > > > * qemu-x86_64 > > > * x86_64-clang

What do you mean by GNU here? The bug is in the Linux kernel, specifically in the code for the ext4 filesystem. There are not many systems out there who runs a GNU kernel.

Re: Linux: Ext4 data corruption in 6.1.64-1

#38

Post by Grimburger »

Animats wrote: post #6

"Causes non-serious data loss". What does that mean. Only affects cat videos?

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.

Re: Linux: Ext4 data corruption in 6.1.64-1

#39

Post by eh8 »

Grimburger wrote: post #38
Animats wrote: post #6

"Causes non-serious data loss". What does that mean. Only affects cat videos?

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.

> Even linux tools like shred have given up saying they can actually delete data from disks due to how SSD's work these days.

Which emphasizes the importance of enabling full disk encryption immediately whenever you start using a new device--BitLocker if you're on Windows, FileVault on macOS, LUKS on Linux, etc. Trying to decrypt data is much harder than reconstructing deleted data on a stolen drive.

Re: Linux: Ext4 data corruption in 6.1.64-1

#40

Post by Roark66 »

Grimburger wrote: post #38
Animats wrote: post #6

"Causes non-serious data loss". What does that mean. Only affects cat videos?

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 really doing that and are not mentioning it in their marketing materials? I never heard that they do that.

Post reply on HN