Re: Corrupt files on hard disk

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Jari Ruusu wrote:

Tommy Back wrote:
ReiserFS: warning: is_tree_node: node level 35571 does not match to the
expected one 1
ReiserFS: loop4: warning: vs-5150: search_by_key: invalid format found
in block 3014659. Fsck?
ReiserFS: loop4: warning: vs-13070: reiserfs_read_locked_inode: i/o
failure occurred trying to find stat data of [1311 1314 0x0 SD]

Any ide driver error messages prior to those messages?

Nope. I have not seen any error messages coming from the driver.

PDC20262: IDE controller at PCI slot 0000:00:0d.0
PDC20262: chipset revision 1
PDC20262: 100% native mode on irq 16
PDC20262: (U)DMA Burst Bit ENABLED Primary PCI Mode Secondary PCI Mode.
   ide2: BM-DMA at 0x6000-0x6007, BIOS settings: hde:DMA, hdf:pio
   ide3: BM-DMA at 0x6008-0x600f, BIOS settings: hdg:DMA, hdh:DMA

Your hdparm and losetup examples used hda. Above info is for hd{e,f,g,h}

Well, the example with /dec/hda was just an example. Actually I have hde,hdg,hdh in use (as you can see above).

I just tried to do some more tests with the partition with corrupt files
and I was really surprised that a file, which was corrupt (I couldn't
delete it as root or move/rename it) was okey and I could delete it. Now
another file was corrupt instead. What is going on here?! I have not
even touched the files since I wrote the mail to the mailing list, so
I'd suppose the same file, which was corrupt in the previous fsck would
be corrupt now as well. Any ideas or comments? Could it be a problem
with Reiserfs?

That sounds like some file metadata was corrupted while it was read from
disk platters to kernel ram. That bad metadata seemed to persist because
kernel cached that corrupted data. Eventually that cached data was dropped
because kernel needed that ram for something else. On new read from disk,
all went ok.
What does that mean exactly? Is it a problem with loop-AES, reiserfs or something else? Is it a persistent problem or just something temporarily? Is it connected to the corruptions I have noticed or is this just something else?

Any chance you could test using ext3 file system?

I'm looking into this. I'll tell you as soon as I have tested it.

Best regards,
Tommy

-
Linux-crypto:  cryptography in and on the Linux system
Archive:       http://mail.nl.linux.org/linux-crypto/


[Index of Archives]     [Kernel]     [Linux Crypto]     [Gnu Crypto]     [Gnu Classpath]     [Netfilter]     [Bugtraq]
  Powered by Linux