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.
In Tulsa, Oklahoma, it is against the law to open a soda bottle without
the supervision of a licensed engineer.
(Score: 4, Informative) by LoRdTAW on Tuesday May 26 2015, @05:34PM
Correct, the proper RAID level for redundancy, also called mirroring, is RAID 1.
RAID 0 is striping which writes data in parallel between two drives increasing read write performance by a factor upward of two. Half of your data is on disk, half on the other. If you lose one disk, you lose everything. Mitigating this is done using RAID 0+1 which is exactly what you'd expect, two RAID 0 arrays which are mirrored. But you are still stuck with losing half of the storage space meaning four 1TB disks gives you only 2TB. The next level up is RAID 5 which has a storage penalty of -1 disk. So a four 1TB disk array will yield 3TB. The parity data is spread across all four (or more) disks in RAID 5 array. You can afford to loose any one of the four disks and still have access to the array. RAID 6 doubles the parity so you can afford to lose two disks.
And remember, RAID 1/5/6 is for redundancy to reduce downtime. It is NOT backup.
(Score: 2) by jmorris on Tuesday May 26 2015, @07:42PM
Yes, RAID5 would yield 3TB vs the 2TB of RAID 1+0 (also called RAID 10). Now look at the cost. A one byte write requires reading all four drives and writing at least two plus calculating and then recalculating the parity. If done in soft RAID it does horrid things to the CPU cache as well. The RAID 10 not only cuts out two reads, both writes are of the same data and none of the unmodified data need pass through the CPU cache if the drivers for the drive interfaces are modern. When writing larger blocks it usually needs to run the data through the cpu cache twice but you might get slightly faster total write throughput in exchange since three drives are sinking the data (plus one more taking parity info) instead of two (plus two taking redundent copies). Which way the performance vs capacity balance swings depends on the intended use. And adding a hardware RAID controller eliminates all of the cache considerations at more upfront expense, system complexity, possible closed array management utilities, etc.
And remember, RAID 1/5/6 is for redundancy to reduce downtime.
Preach brother! Filesystem corruption, accidental deletion, power surge, all these things can totally hose you despite RAID.
(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