51–60 of 202 posts
Earlier quoted context omitted.
Does OpenZFS have a similar ratio of bad to good posts?
ZFS's killer feature is religious inspiration. Write holes during resilvers are healthy and natural, but the same in a software RAID 5/6 configuration on BTRFS is unacceptably risky. Brought to you by the same people who don't think SMR disks are used with ZFS in enterprise.
I had multiple corruption on a "server" at my parents, checked the disk and reinstalled from scratch 2 times, then I ran memtest86+ and found out one of the memory stick was faulty. Btrfs allowed me to detect that and be confident that all data recovered from the disks were ok because of the data checksumming. With ext4 I might have never found out.
I wish to god people would get a clue with BTRFS: - don't use it because you think the name is "cool". Every time I go to a linux meetup, some idiot starts talking about the name. - it takes 5-10 years for a filesystem or database to mature after it's released. Otherwise you will lose data and cry. - the recent BTRFS performance improvements are against itself, not other filesystems. EXT4 is an excellent fs, as good…
Great news! BTRFS was introduced in the mainline kernel in March 2009! It's been ten years.
The ratio of bad to good posts about BTRFS always made me wonder why anyone would roll with it. Don’t put your fs in crazy.
The ratio of bad to good posts has always stunned me too. But for the opposite reason. The linked post explains that there is a performance regression in a very rare and specific usecase: creating 100k files in a short span of time. And I'm not talking about unpacking boost, that's not enough files. Additionally, it will be fixed before any distro packages it. (even Arch is still on 5.9.14.) On the other hand btrfs g…
In JavaScript world that's really not that much. A project I've been working on has 120k+ files in node_modules, and `yarn install` creates the whole directory tree in a few seconds. It's not some obscure issue nobody ever runs into.
This version has got to be the worst kernel released in a while in terms of regression, from AMDGPU null pointer dereference crash[0] to f2fs data corruption bug[1] and now this. Fixes for these are on their way as far as I can tell but since the stable team are probably on Christmas vacation it might take a while. [0] https://bbs.archlinux.org/viewtopic.php?pid=1943906#p1943906 [1] https://bugzilla.kernel.org/show_b…
Earlier quoted context omitted.
Please understand that the rust memory and thread security mainly applies to "normal" applications. In kernel, you can run a privileged cache or mmu instruction or a write to some magical memory position and all the sudden the "normal" rules don't apply anymore. (But I think there are other parts of rust that are nice to have in kernel or any complex software).
I thought the Rust compiler solves issues that you wouldn't immediately see with pure C, which is why I had the idea. I didn't know this requires certain features which are not available inside the kernel. I only knew all existing interfaces may be unsafe because they are in C though. Rust does not seem as useful then. Thank you for your input.
This version has got to be the worst kernel released in a while in terms of regression, from AMDGPU null pointer dereference crash[0] to f2fs data corruption bug[1] and now this. Fixes for these are on their way as far as I can tell but since the stable team are probably on Christmas vacation it might take a while. [0] https://bbs.archlinux.org/viewtopic.php?pid=1943906#p1943906 [1] https://bugzilla.kernel.org/show_b…
I had multiple corruption on a "server" at my parents, checked the disk and reinstalled from scratch 2 times, then I ran memtest86+ and found out one of the memory stick was faulty. Btrfs allowed me to detect that and be confident that all data recovered from the disks were ok because of the data checksumming. With ext4 I might have never found out.
I wouldn't count on that though. I'd say you were lucky. If the corruption happens before it gets sent to the disk, then you have checksummed and valid but broken data.