Live data from Hacker News

Linux: Ext4 data corruption in 6.1.64-1

bugs.debian.org

71–80 of 138 posts

Re: Linux: Ext4 data corruption in 6.1.64-1

#71
post #40

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…

> I never heard that they do that.

Not sure how you missed it, as it's not a new thing. Straight from the horses mouth, if that helps: :)

https://www.kingston.com/en/blog/pc-performance/overprovisio...

Note that it's not just a Kingston thing, it's common across SSD manufacturers. Or at least with the major ones.

Re: Linux: Ext4 data corruption in 6.1.64-1

#74
post #44

The irony of seeing this, after Linus remarks how serious and thorough the file system kernel developers are, versus the other device drivers developers.

https://lore.kernel.org/stable/20231205122122.dfhhoaswsfscuh...

It seems like a commit from the main branch was backported to stable branch, but it actually depended on another one which was not backported.

Linux kernel maintainers heavily backport commits as it seems the distinction between bug-fix and new features is hard to do. Also, bug-fix can depend on new features..

I'm always a bit scared when I look at the amount of commits in a single stable kernel point release, plus the fact that these point releases come out every week or so. The velocity of change in what should be a stable kernel is very high.

I'm wondering who exactly wants to run a stable kernel that receives all these updates so fast. If you want all the latest and greatest, just use -latest?

Re: Linux: Ext4 data corruption in 6.1.64-1

#75

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.

No, the issue was caused by backporting a patch A but not backporting a patch B. Sadly in this case the overall behavior after applying just A was broken when issuing direct IO writes.

Re: Linux: Ext4 data corruption in 6.1.64-1

#77
post #63
post #6

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

Reminds me of this exchange from Coupling (UK): “How is it not serious if she died from it?” “She made an unsuccessful recovery”

Funny, I also thought of Coupling, except I was thinking of

- how badly can you phrase yes?

[Cuts to other scene]

- No

Such a good show.

Re: Linux: Ext4 data corruption in 6.1.64-1

#78
post #34

Three months using kernel 6.6.5 from Zabbly (for hardware support) and having no issues: https://github.com/zabbly/linux Quote "As those kernels aren't signed by a trusted distribution key, you may need to turn off Secure Boot on your system in order to boot this kernel."

6.6.5 was released 2 days ago and 6.6 a month ago :)

Re: Linux: Ext4 data corruption in 6.1.64-1

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

Tbf, you also would have to explicitly enable automatic reboots (or manually reboot after the new kernel).

That said, I certainly wouldn’t blame anyone for blindly trusting a kernel in Stable. This hurts.

Post reply on HN