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

131–138 of 138 posts

Re: Linux: Ext4 data corruption in 6.1.64-1

#131

Post by frankjr »

frankjr wrote: post #88

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 h…

Did you update to 6.1.66? Sucker! Your data might be safe(r) but your Wi-Fi is not working! The exact same thing happened again ([0] needs [1] but that one was not backported). Fixed in 6.1.67 [2] released this morning.

[0] https://github.com/torvalds/linux/commit/7e7efdda6adb385fbdf...

[1] https://github.com/torvalds/linux/commit/076fc8775dafe995e94...

[2] https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.1.6...

Re: Linux: Ext4 data corruption in 6.1.64-1

#132

Post by megous »

keep_reading wrote: post #123
megous wrote: post #102

Earlier quoted context omitted.

Fedora, openSUSE tumbleweed, Manjaro,...

> Fedora You know it's not that hard to debunk this: > You'll then be left with a kernel-6.X.? directory, containing both an unpatched 'vanilla-6.X.?' dir, and a linux-6.X.?-noarch hardlinked dir which has the Fedora patches applied. [1] WOW fedora patches! Sounds to me like they're not shipping vanilla. [1] https://fedoraproject.org/wiki/Kernel

That's not what my original argument was about. So not sure what you're debunking.

I have problem with backaptching 10s of thousands of changes to years old kernels by people who don't really understand the changes or consequences, like 5.4, 5.15, 6.1 or whatever. Not patching up 6.6 or 6.7 kernel with a few out of tree patches, where they mostly understand what they're doing and can test the limited set of changes they're applying.

Re: Linux: Ext4 data corruption in 6.1.64-1

#135

Post by grrandalf »

mustache_kimono wrote: post #122
nolist_policy wrote: post #113

Earlier quoted context omitted.

Note though that unlike zfs, ext4 has a battle-tested fsck. Combine ext4's dumb but robust approach to journaling and robust metadata layout (for example inodes are statically allocated) with fsck.ext4 (which got refined for years) and you can recover from any situation. To give you an example, fsck.ext4 will happily carve a working filesystem out of random data, as long as there is a valid superblock. Seriously - tr…

I'm trying to understand what exactly this is testing/demonstrating. Like: "Wow, but why should I care?" I'm not sure being able to fsck a random disk image shows resiliency. Doing this could do all sorts of nasty things to data you actually care about.

(not the author) The metadata is a contiguous range of disk blocks. I think the intuition is that such layouts are likely to require simpler filesystem code to manipulate. [versus (iirc) ZFS which may have metadata blocks scattered throughout the disk, probably requiring more intricate code to keep track of].

Re: Linux: Ext4 data corruption in 6.1.64-1

#136

Post by mustache_kimono »

grrandalf wrote: post #135
mustache_kimono wrote: post #122

Earlier quoted context omitted.

I'm trying to understand what exactly this is testing/demonstrating. Like: "Wow, but why should I care?" I'm not sure being able to fsck a random disk image shows resiliency. Doing this could do all sorts of nasty things to data you actually care about.

(not the author) The metadata is a contiguous range of disk blocks. I think the intuition is that such layouts are likely to require simpler filesystem code to manipulate. [versus (iirc) ZFS which may have metadata blocks scattered throughout the disk, probably requiring more intricate code to keep track of].

> [versus (iirc) ZFS which may have metadata blocks scattered throughout the disk, probably requiring more intricate code to keep track of].

So -- you think redundant metadata is a bad thing? Try wiping your metadata and then trying to fsck that random disk image.

Again, has this been the source of data corruption you're aware of? This seems like a "Maybe, it could be this way, but I don't know" kind of take.

Re: Linux: Ext4 data corruption in 6.1.64-1

#137

Post by keep_reading »

megous wrote: post #132
keep_reading wrote: post #123

Earlier quoted context omitted.

> Fedora You know it's not that hard to debunk this: > You'll then be left with a kernel-6.X.? directory, containing both an unpatched 'vanilla-6.X.?' dir, and a linux-6.X.?-noarch hardlinked dir which has the Fedora patches applied. [1] WOW fedora patches! Sounds to me like they're not shipping vanilla. [1] https://fedoraproject.org/wiki/Kernel

That's not what my original argument was about. So not sure what you're debunking. I have problem with backaptching 10s of thousands of changes to years old kernels by people who don't really understand the changes or consequences, like 5.4, 5.15, 6.1 or whatever. Not patching up 6.6 or 6.7 kernel with a few out of tree patches, where they mostly understand what they're doing and can test the limited set of changes t…

If they change anything it's no longer vanilla. Anything at all. No matter how insignificant.

Re: Linux: Ext4 data corruption in 6.1.64-1

#138

Post by n3storm »

megous wrote: post #78
n3storm wrote: 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 :)

6.5 is available too.

Anybody would be so kind to tell me why I have been downvoted?

Post reply on HN