SoylentNews is people
SoylentNews
The combination of RAID0 redundancy, an ext4 filesystem, a Linux 4.x kernel, and either Debian Linux or Arch Linux has been associated with data corruption.
El Reg reports EXT4 filesystem can EAT ALL YOUR DATA
Fixes are available, one explained by Lukas Czerner on the Linux Kernel Mailing List. That post suggests the bug is long-standing, possibly as far back as the 3.12-stable kernel. Others suggest the bug has only manifested in Linux 4.x.
[...] This patch for version 4.x and the patched Linux kernel 3.12.43 LTS both seem like sensible code to contemplate.
[Editor's Comment: Original Submission]
This discussion has been archived.
No new comments can be posted.
Running an ext4 RAID0 with a Linux 4.x Kernel? Better Spray for Bugs
|
Log In/Create an Account
| Top
| 45 comments
| Search Discussion
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Love is the delusion that one woman differs from another.
-- H. L. Mencken
(Score: 3, Informative) by TheRaven on Wednesday May 27 2015, @01:22PM
A one byte write requires reading all four drives and writing at least two plus calculating and then recalculating the parity
You don't write bytes to block devices, you write blocks. Blocks are generally stored in the buffer cache and most RAID arrangements write stripes in such a way that they're normally read and cached similarly (e.g. logical blocks n to n+m in an m-way RAID set are blocks 0 to m in a single stripe). You will need to do a read before doing a write if you're writing somewhere that isn't in the buffer cache, but this is a comparatively rare occurrence.
If done in soft RAID it does horrid things to the CPU cache as well.
That's far less true on modern CPUs. Intel can do xor in the DMA controller, so you don't actually need it to come closer to the CPU than LLC anyway, but even without that most CPUs support non-temporal loads (and will automatically prefetch streaming memory access patterns) and uncached stores, so you will not trample the cache too much. At most you should be killing one way in each associative cache, so an eighth to a quarter of the cache (depending on the CPU), if implemented correctly.
sudo mod me up