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

41–50 of 138 posts

Re: Linux: Ext4 data corruption in 6.1.64-1

#41

Post by Roark66 »

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.

What if you build your own kernel from kernel.org, but you use Debian tools to make dpkgs? (and you use old config)?

Re: Linux: Ext4 data corruption in 6.1.64-1

#42

Post by tux2bsd »

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.

[dead]

Re: Linux: Ext4 data corruption in 6.1.64-1

#43

Post by Grimburger »

eh8 wrote: post #39
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.

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

True, properly zeroing out the headers on an encrypted drive will make recovery impossible.

How to do that reliably is another question.

Re: Linux: Ext4 data corruption in 6.1.64-1

#45

Post by Grimburger »

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…

Sure, but very few business tools are doing that, they are playing the old Gutmann game which he himself has walked away from as not reliable anymore. Filling up the drive is certainly getting you somewhere compared to some of the snake-oil out there. Drives are only getting bigger though and rarely filled up, done some of this stuff in my time and if cost is no barrier then you'd be surprised how much can be reclaimed. Degauss and destroy is the only real method we have now and that's probably not changing in future.

>but are manufacturers really doing that and are not mentioning it in their marketing materials

SSD manufacturers have been caught out repeatedly with their in-built deletion API claims. Recovery of a significant % of files is possible nearly always without tampering having occurred.

Re: Linux: Ext4 data corruption in 6.1.64-1

#46

Post by 15457345234 »

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.

[flagged]

Re: Linux: Ext4 data corruption in 6.1.64-1

#48

Post by colechristensen »

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…

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

Every SSD has considerably more physical blocks than reported blocks. They have to, SSD bad blocks are common and number of writes is quite limited compared to hard disks.

https://download.semiconductor.samsung.com/resources/others/...

Re: Linux: Ext4 data corruption in 6.1.64-1

#49

Post by megous »

uselpa wrote: post #29
megous wrote: post #8

Earlier quoted context omitted.

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.

A bunch of popular distros run the latest kernel.
Post reply on HN