Slashdot Mirror
Linux 4.0 Has a File-System Corruption Problem, RAID Users Warned
An anonymous reader writes: For the past few days kernel developers and Linux users have been investigating an EXT4 file-system corruption issue affecting the latest stable kernel series (Linux 4.0) and the current development code (Linux 4.1). It turns out that Linux users running the EXT4 file-system on a RAID0 configuration can easily destroy their file-system with this newest "stable" kernel. The cause and fix have materialized but it hasn't yet worked its way out into the mainline kernel, thus users should be warned before quickly upgrading to the new kernel on systems with EXT4 and RAID0.
md raid. The bug was in commit md/raid0: fix bug with chunksize not a power of 2 causing, you guessed it, a bug with a chunksize not a power of two. I guess "fix" was a bit diversionary.
The real problem was a macro modifying arguments that were later expected to be the unmodified version.
That patch also says that the bug exists since Linux 3.14. So it is NOT 4.0, but every kernel since 3.14 that is affected here.
It's stable as in terms of features and changes. i.e. No longer under development and will only receive fixes.
However! Kernels from kernel.org are not for end users, if someone is using these kernels directly then they do so at their own risk.
They are intended for integrators (distributions), whose integration will include their own patches/changes, testing, QA and end user support
There is a reason that RHEL 7 is running Kernel 3.10 and Debian 8 is running 3.16. Those are the 'stable' kernels you were expecting.
When kernel development moved from 2.5 to 2.6 (that later became 3.0), they stopped their odd/even number development/stable-release cycle. Now there is only development, and the integrators are expected to take the output of that to create stable-releases.
No. There was a minor bug introduced at 3.14. The patch to fix that, completely different issue, went into 4.0 and caused this corruption issue.
"National Security is the chief cause of national insecurity." - Celine's First Law
You really should get out more. ZFS on Linux is not to be confused with the ZFS Fuse project. You can boot from a ZoL filesystem. In general ZoL is about as stable, complete, and reliable as any ZFS.
That fix is actually in the wrong place. The fix for that is tracked in kernel.org's bugzilla # 98501. I'm not linking directly as linking to bugzilla tends to place too high a load on those systems. It's impolite.
Neil Brown said that he'd push the fix to Linus "shortly" at 2015-05-20 23:06:58 UTC. I still don't see the fix in Linus' tree.
Watch for a fix titled "md/raid0: fix restore to sector variable in raid0_make_request"
Losing data goes with the territory if you're going to use RAID 0.
In particular, RAID 0 combines disks with no redundancy. It's JUST about capacity and speed, striping the data across several drives on several controllers, so it comes at you faster when you read it and gets shoved out faster when you write it. RAID 0 doesn't even have a parity disk to allow you to recover from failure of one drive or loss of one sector.
That means the failure rate is WORSE than that of an individual disk. If any of the combined disks fails, the total array fails.
(Of course it's still worse if a software bug injects additional failures. B-b But don't assume, because "there's a RAID 0 corruption bug", that there is ANY problem with the similarly-named, but utterly distinct, higher-level RAID configurations which are directed toward reliability, rather than ONLY raw speed and capacity.)
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
Based on the commit fixes, it's in a function called raid0_make_request, which is only used in raid0.c
raid 10 is in raid10.c, so it doesn't use this function.
The bug is based on the fact that a macro "sector_div" modifies it's first argument [and returns the remainder]. I've removed the obligatory backslashes for clarity:
# define sector_div(n, b)( /= (b);
{
int _res;
_res = (n) % (b);
(n)
_res;
}
)
This is used in some fifty files. Some just want the remainder [and they don't want the first arg changed so they do]:
sector_t tmp = sector;
rem = sector_div(tmp,blah);
This is effectively what the code wanted, but the actual fix was to do a restore afterwards:
sector_t sector = myptr->sector;
...
rem = sector_div(sector,blah);
...
sector = myptr->sector;
... // use sector [original value only please ;-)]
The last line to restore sector with the original value was the fix.
They should do a full code audit as their may be other places that could be a problem. I've reviewed half the files that use this macro and while they're not broken, some of the uses are fragile. I paraphrase: "sector_div considered harmful"
What they really need are a few more variants which are pure functions that could be implemented as inlines:
rem = sector_rem_pure(s,n)
s2 = sector_div_pure(s1,n)
Or, a cleaner sector_div macro:
sector_div_both(s,n,sector_return,rem_return)
Like a good neighbor, fsck is there