EXT3-fs error



This is 2.6.8.

In messages:
Aug 31 08:22:34 mail04 kernel: EXT3-fs error (device cciss/c0d1p1):
ext3_add_entry: bad entry in directory #14058742: rec_len is smaller
than minimal - offset=0, inode=0, rec_len=0, name_len=0
Aug 31 08:22:34 mail04 kernel: Aborting journal on device cciss/c0d1p1.
Aug 31 08:22:34 mail04 kernel: ext3_abort called.
Aug 31 08:22:34 mail04 kernel: EXT3-fs error (device cciss/c0d1p1):
ext3_journal_start_sb: <2>ext3_abort called.
Aug 31 08:22:34 mail04 kernel: EXT3-fs error (device cciss/c0d1p1):
ext3_journal_start_sb: Detected aborted journal
Aug 31 08:22:34 mail04 kernel: Remounting filesystem read-only
Aug 31 08:22:34 mail04 kernel: journal commit I/O error
Aug 31 08:22:34 mail04 last message repeated 4 times
Aug 31 08:22:34 mail04 kernel: Detected aborted journal
Aug 31 08:22:34 mail04 kernel: EXT3-fs error (device cciss/c0d1p1) in
ext3_link: IO failure
Aug 31 08:22:34 mail04 kernel: EXT3-fs error (device cciss/c0d1p1):
ext3_readdir: bad entry in directory #14058742: rec_len is smaller than
minimal - offset=0, inode=0, rec_len=0, name_len=0
Aug 31 08:22:34 mail04 kernel: journal commit I/O error

The file system was remounted which seems to clear the error:
Aug 31 09:16:02 mail04 kernel: EXT3-fs error (device cciss/c0d1p1):
ext3_remount: Abort forced by user
Aug 31 09:17:31 mail04 kernel: __journal_remove_journal_head: freeing
b_committed_data
Aug 31 09:17:31 mail04 last message repeated 6 times
Aug 31 09:18:05 mail04 kernel: kjournald starting. Commit interval 5
seconds
Aug 31 09:18:05 mail04 kernel: EXT3-fs warning (device cciss/c0d1p1):
ext3_clear_journal_err: Filesystem error recorded from previous mount:
IO failure
Aug 31 09:18:05 mail04 kernel: EXT3-fs warning (device cciss/c0d1p1):
ext3_clear_journal_err: Marking fs in need of filesystem check.
Aug 31 09:18:05 mail04 kernel: EXT3-fs warning: mounting fs with
errors, running e2fsck is recommended
Aug 31 09:18:05 mail04 kernel: EXT3 FS on cciss/c0d1p1, internal
journal
Aug 31 09:18:05 mail04 kernel: EXT3-fs: recovery complete.
Aug 31 09:18:05 mail04 kernel: EXT3-fs: mounted filesystem with ordered
data mode.

My question:
How do I determine what is/was contained in "directory #14058742"?

Running e2fsck is really not an option right now as this is a
production server and a very large volume (300GB with 150GB used).

TIA, Rich
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/



Relevant Pages

  • Re: [patch] ext2/3: document conditions when reliable operation is possible
    ... when the power fails, the disk either writes a particular disk block, ... Now consider a file system which does logical journalling. ... down pending DMA transfers to prevent this failure mode from causing ...
    (Linux-Kernel)
  • Re: power down file system protection in RTOS ?
    ... file system corruption. ... Except for hardware faults, why would would you need any of this? ... Many file servers use RAID level 5, ... failure or a hard disk failure with less overhead. ...
    (comp.realtime)
  • Re: raid is dangerous but thats secret (was Re: [patch] ext2/3: document conditions when reliable op
    ... a second failure. ... +sectors are also damaged during the power failure. ... +corruption resulting in file system corruption, ...
    (Linux-Kernel)
  • Re: Whither RAID?
    ... > correct and regular backup strategy can save you from the sort of failure ... not to corrupt the local file system): use RAID plus some form of snapshot ... Given the size of today's disks, creating a file system which either never ...
    (comp.os.vms)
  • Re: power down file system protection in RTOS ?
    ... Philip Martel wrote: ... file system corruption. ... What you have described sounds similar to RAID level 1. ... http://en.wikipedia.org/wiki/Redundant_array_of_independent_disks Many file servers use RAID level 5, which allows recovery after power failure or a hard disk failure with less overhead. ...
    (comp.realtime)