2.5.49: Severe PIIX4/ATA filesystem corruption
So, I finally braved it and tried running 2.5.49 on my workstation to test out my RAID-6 patches. There were no patches outside the md area, and the ordinary filesystems aren't on md drives.
The two SCSI drives (SymBIOS controller) work just fine, but I have gotten repeated, severe data corruption on the one ATA drive in the system after only a few hours of operation.
Just thought I'd warn people...
-hpa
Signature · 3 lines
<[email protected]> at work, <[email protected]> in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt <[email protected]>
Quoted 7 lines · H. Peter Anvin
So, I finally braved it and tried running 2.5.49 on my workstation to test out my RAID-6 patches. There were no patches outside the md area, and the ordinary filesystems aren't on md drives.
The two SCSI drives (SymBIOS controller) work just fine, but I have gotten repeated, severe data corruption on the one ATA drive in the system after only a few hours of operation.
If you mash the innards of the page cache you'll get corruption everywhere, its one of the charms of testing out that area of the code on Linux. You might want to debug using 2.5.49 user mode linux rather than on raw disks. Its so much easier to use "cp" to generate a replacement root_fs 8)
Alan
Quoted 11 lines · Alan Cox
Quoted 7 lines · H. Peter Anvin
So, I finally braved it and tried running 2.5.49 on my workstation to test out my RAID-6 patches. There were no patches outside the md area, and the ordinary filesystems aren't on md drives.
The two SCSI drives (SymBIOS controller) work just fine, but I have gotten repeated, severe data corruption on the one ATA drive in the system after only a few hours of operation.
Quoted 6 lines
If you mash the innards of the page cache you'll get corruption everywhere, its one of the charms of testing out that area of the code on Linux. You might want to debug using 2.5.49 user mode linux rather than on raw disks. Its so much easier to use "cp" to generate a replacement
root_fs8)
Yes, that's true. However, the heavily used two SCSI disks saw no corruption whatsoever, whereas the single, lightly used ATA disk saw heavy corruption; if it was due to experimental unrelated code one would have expected corruption everywhere. This does not mean that it is not my fault (as far as UML is concerned, I tried building it quite a few times before giving up), but given the severity of the corruption I was seeing I thought I'd raise a red flag.
-hpa
Quoted 4 lines · H. Peter Anvin
Yes, that's true. However, the heavily used two SCSI disks saw no corruption whatsoever, whereas the single, lightly used ATA disk saw heavy corruption; if it was due to experimental unrelated code one would have expected corruption everywhere. This does not mean that it is not
IDE does handle the I/O quite differently so Im not sure about that. Accidentally fiddling with an in flight request tends to do horrible things on IDE but not on scsi for example.
The base 2.5.47/8/9 Linus tree PIIX code has had no corruption reports (except someone whose box failed memtest86) and its about the most tested IDE controller.
I would be interested to know what happens if you boot a base 2.5.49 without raid6 adulteration and stress it on your hw there, just to be sure.
Quoted 9 lines · Alan Cox
The base 2.5.47/8/9 Linus tree PIIX code has had no corruption reports (except someone whose box failed memtest86) and its about the most tested IDE controller.
I would be interested to know what happens if you boot a base 2.5.49 without raid6 adulteration and stress it on your hw there, just to be sure.
I will try it once the system gets put back together, which will be in about two weeks (we're moving, and today was computer teardown day.) All I have ATM is my laptop, which I won't be running experimental stuff on :-/
-hpa
Followup to: <[email protected]> By author: Alan Cox <[email protected]> In newsgroup: linux.dev.kernel
Quoted 5 lines
I would be interested to know what happens if you boot a base 2.5.49 without raid6 adulteration and stress it on your hw there, just to be sure.
Well, I finally got the system up and running again, after moving, and ran it without loading any of the md modules (thus nothing modified by the raid6 code.) Leaving it running overnight at the shell prompt but cron jobs running -- including the one that backs up the SCSI drives onto the IDE drive -- left me with tons of ext3fs error messages in the morning on the IDE drive in question.
This is unfortunately all the information I have right at the moment.
-hpa
Signature · 3 lines
<[email protected]> at work, <[email protected]> in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt <[email protected]>