<div dir="ltr"><br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div dir="ltr"><div class="gmail_quote"><div>It sounds like your filesystem is hosed, have you tried booting into single user mode and runing fsck over the FS? (rather than just relying on the journal) The lockup when you try and do certain things sounds like FS corruption (maybe it's getting stuck in an endless loop when traversing inodes or something??)<br>
<br>The fact things end up in lost+found suggest this also (as this is where FS recovery code will reattach stuff it finds.)<br><br>fsck is the way to go.</div></div></div></blockquote><div> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div dir="ltr"><div class="gmail_quote"><div>This makes me think it's filesystem corruption even more. The raid gives you a fault tolerant block device, it knows nothing about the data that's on that device, so if your filesystem gets corrupted the raid will quite happily give you redundancy for your broken data. <br>
</div></div></div></blockquote><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div dir="ltr"><div class="gmail_quote"><div><br>However, as you have RAID a single failing disc shouldn't cause the kind of issues you're having (or at least not without timing out and degrading the RAID.)<br>
<br>If it does turn out to be FS corruption you're probably best newfsing, but at the least you should /copy/ rather than move affected files. It stands a slightly better chance of working. (moving files can just alter a few on disc pointers, whereas copying will copy the affected data, so you won't recover corrupted files, but you won't have any files that are corrupted lyring around wating to trip you up.)<br>
</div></div></div></blockquote><div><br>I choose creating a new fs as I think the JFS filesystem is definitely corrupted. Most of you are thinking of software troubleshooting, so I will prefer EXT3 for this new fs. It is less efficient for recordings (big files) but more robust, I think.<br>
So as to be sure it is not a hardware issue, I used badblocks as mentioned by Alex.<br><pre class="wiki">badblocks -n -s /dev/sdb<br>Checking for bad blocks (non-destructive read-write test)<br>Testing with random pattern: done<br>
</pre>I also used smartctl -t long /dev/sdb which doesn't log any error. So I think the harddisk is healthy. I am going to apply this check on the other harddisk to be sure it is a software troubleshooting.<br>Shouldn't smartctl be enough ?<br>
Is there a best way to check harddisk ?<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div dir="ltr"><div class="gmail_quote"><div>
<br>Cheers<br><br>Ian</div></div></div></blockquote><div> </div></div>Kind regards<br><br></div>