On SL4, I've had a hard drive go bad with two bad sectors.  This is the first time I've seen in /var/log/messages, errors like:

art_transaction: Journal has aborted
EXT3-fs error (device hda3) in start_transaction: Journal has aborted
EXT3-fs error (device hda3) in start_transaction: Journal has aborted
...
File system was mounted read only and linux would not reboot.

Nothing else I could find.    Booted into knoppix and smartctl would not complete a test - so bad blocks.  There were 2.  I run smartctl almost religiously (twice a week), so, I caught this early.  I'm copying over the disk to a new one using ddrescue via knoppix.

Googling, I see
a) a kernel patch in regard to journal abortion (which I don't think applies to me)
b) suggested approach... jourrnal gone, so convert to ext2, do a fsck, then convert back to ext3
tune2fs -O ^has_journal  /dev/hda3
e2fsck /dev/hda3
tune2fs -j  /dev/hda3
Several people reported that this worked cleanly and problem went away.  I'm not sure they had bad blocks though.

Now, my questions
1.   Is the aborted journal error something that happens now with bad blocks in SL4 that didn't occur in SL3? 
2.  What does the aborted journal imply that is different than finding smartctl did not complete a test (bad blocks). 
3.  Is it preferrrable to convert to ext2 since journal gone, the approach in b), or is e2fsck clever enough to manage this with filesystem kept in ext3?

I should add as a wrinkle, that I dealt with the two bad blocks by looking at the smartctl percentage completion and running spinrite.  I currently no longer have bad blocks on HD.  If I had more serious problem, I've have gone to ddrescue immediately. 

Bill Lutter

Bill Lutter