Martin Braure de Calignon wrote:
> I'm experiencing frequent data corruption on my raid1 ext4 fs.
> The error is not always the same.
>
> I first thought it was due to a previous resize of the FS I've done.
> I had multiple times some message about huge amount of multiply claimed
> blocks in inode .
> fsck.ext4 was not working fully and was always ending with a message like "FS
> still have error".
> I was unable to copy all the files to another FS to save it.
> So I end up checking the badblocks (that's where I've been dumb, I choose a
> non data conservative way).
> However, badblock was succesful without errors.
> So in the end I lost some data, however, I don't know if it's due to the bug
> or the the badblocks check. So feel free to readjust severity.
>
> Since theni, I have bought two brand new disks, created a completly new ext4
> FS, and copied the files that I had succesfully recovered.
> Then I run fsck.ext4 on the FS... it seems it is almost working.
> I'm remounting the /dev/md0... And each time I start using the system
> seriously, I have new errors, like the one I had today:
> (I was just copying files on it)
[...]
> [1436849.120036] EXT4-fs (md0): error count: 6
> [1436849.120044] EXT4-fs (md0): initial error at 1371763084:
> htree_dirblock_to_tree:587: inode 20971803: block 83894316
> [1436849.120054] EXT4-fs (md0): last error at 1371765809:
> htree_dirblock_to_tree:587: inode 41813096: block 167256110
> [1446656.923648] EXT4-fs error (device md0): htree_dirblock_to_tree:587:
> inode #52698372: block 210773049: comm smbd: bad entry in directory:
> directory entry across blocks - offset=1052(9244), inode=1949184565,
> rec_len=29816, name_len=24
[...]
The kernel log also showed the CPU was reaching its temperature limit,
but after he cleaned out the CPU cooler and corrected the CPU frequency
the problem persisted. I suggested swapping disks between controllers:
On Fri, 2013-06-28 at 15:55 +0200, Martin Braure de Calignon wrote:
[...]
> So as planned I unplugged the working non RAID1 disk from their
> controller, and connect the ext4 RAID1 and the ext3 RAID1 disk to it
> (yeah these are 2 powerful RAID1 with 1 device only ;) for testing
> purposes).
> I also tried to re-plug each PCI card, and connect the video card fan
> that was not connected (yeah it was a bad idea to limit the noise level
> few years ago).
>
> I did all the tests I could to try to overheat the system (same as
> yesterday):
> * 4 running dd if=/dev/urandom | gzip >/dev/null for the cpu
> * massive copy from one disk to the other
> * delete of duplicates between two directories (with many duplicates)
>
> All that in parallel. Everything seems to work fine. No corruption nor
> CPU overheating message (yesterday I still had some even after remove
> the overclock of the CPU).
[...]
> Here's the lspci - for this card (if I'm not wrong):
>
> 02:09.0 SATA controller: Initio Corporation INI-1623 PCI
> SATA-II Controller (rev 02) (prog-if 00 [Vendor
> specific])
> Subsystem: Initio Corporation Device 1626
> Control: I/O+ Mem+ BusMaster+ SpecCycle-
> MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
> DisINTx-
> Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr-
> DEVSEL=medium >TAbort- SERR- INTx-
> Latency: 32, Cache Line Size: 32 bytes
> Interrupt: pin A routed to IRQ 17
> Region 0: I/O ports at 9000 [size=256]
> Region 1: Memory at ef022000 (32-bit,
> non-prefetchable) [size=4K]
> [virtual] Expansion ROM at 8000 [disabled]
> [size=128K]
> Capabilities: [dc] Power Management version 2
> Flags: PMEClk+ DSI- D1+ D2+
> AuxCurrent=0mA PME(D0-,D1+,D2+,D3hot+,D3cold-)
> Status: D0 NoSoftRst- PME-Enable- DSel=0
> DScale=0 PME-
> Kernel driver in use: sata_inic162x
[...]
So this does seem to be a fault in either this card or the driver. Can
you suggest any further tests that Martin could do?
Ben.
--
Ben Hutchings
Sturgeon's Law: Ninety percent of everything is crap.
signature.asc
Description: This is a digitally signed message part
