EXT3-fs error (device dm-10)

ext3rhel5

I got this log error below:

Aug  1 20:44:01 TDBP24LV kernel: EXT3-fs error (device dm-10): ext3_free_blocks_sb: bit already cleared for block 8159746
Aug  1 20:44:01 TDBP24LV kernel: EXT3-fs error (device dm-10): ext3_free_blocks_sb: bit already cleared for block 8159747
Aug  1 20:44:01 TDBP24LV kernel: EXT3-fs error (device dm-10): ext3_free_blocks_sb: bit already cleared for block 8159748
Aug  1 20:44:01 TDBP24LV kernel: EXT3-fs error (device dm-10): ext3_free_blocks_sb: bit already cleared for block 8159749
Aug  1 20:44:01 TDBP24LV kernel: EXT3-fs error (device dm-10): ext3_free_blocks_sb: bit already cleared for block 8159750
Aug  1 20:44:01 TDBP24LV kernel: EXT3-fs error (device dm-10): ext3_free_blocks_sb: bit already cleared for block 8159751
Aug  1 20:44:01 TDBP24LV kernel: EXT3-fs error (device dm-10) in ext3_free_blocks_sb: Journal has aborted
Aug  1 20:44:01 TDBP24LV kernel: EXT3-fs error (device dm-10) in ext3_reserve_inode_write: Journal has aborted
Aug  1 20:44:01 TDBP24LV kernel: EXT3-fs error (device dm-10) in ext3_truncate: Journal has aborted
Aug  1 20:44:01 TDBP24LV kernel: EXT3-fs error (device dm-10) in ext3_reserve_inode_write: Journal has aborted
Aug  1 20:44:01 TDBP24LV kernel: EXT3-fs error (device dm-10) in ext3_orphan_del: Journal has aborted
Aug  1 20:44:01 TDBP24LV kernel: EXT3-fs error (device dm-10) in ext3_reserve_inode_write: Journal has aborted
Aug  1 20:44:01 TDBP24LV kernel: EXT3-fs error (device dm-10) in ext3_delete_inode: Journal has aborted
Aug  1 20:44:01 TDBP24LV kernel: EXT3-fs error (device dm-10): ext3_journal_start_sb: Detected aborted journal

Could someone help?

Best Answer

Probably your filesystem switched automatically to readonly mode until now.

It is a general failure in your fs. It was probably caused by a write failure.

If your fs is yet writable, mount it to readonly (mount /the/fs/mount/path -o remount,ro). If you can't do that, first you had to kill any process who wants/could write anything there (you can find them with an lsof -n|grep /the/fs/mount/path).

Then run a hard filesystem check (e2fsck -f -p -C0 /dev/device/path). If you don't like to press y a thousand times, use a -y flag instead of -p as well - although in this case you will say automatically "yes" to every, potentially destructive actions of the filesystem repair tool.

After that, you could remount it writable again (mount /the/fs/mount/path -o remount,rw).

If you can reboot without problems (i.e. you aren't working on your parters mission critical server 5000 km awhile), it weren't surely a bad practice to make this from a the root shell of a readonly rescue system.

You can calculate with same data loss as well, although don't have any real fear from such cryptic error messages, even if there are so many. Your filesystem has probably only a few damage, yet.

Related Topic