Re: ext3 fs errors 3T fs

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

 



On Jan 20, 2006  23:07 -0800, Dennis Williams wrote:
> After the fsck finished this evening there were no final statements
> refering to problems.  I remounted the filesystem without any errors.
> After noticing that there were a number of files missing, I started to
> attempt to recover from the lost+found directory.  I was repeatedly able
> to get the the filesystem to error and remount read only when find
> traversed a specific directory in lost+found.  This is the error message I
> recieved from /var/log/messages:
> 
> Jan 21 16:00:26 terrorbytes kernel: EXT3-fs error (device md0):
> ext3_readdir: bad entry in directory #73117155: directory entry across
> blocks - offset=0, inode=0, rec_len=8196, name_len=84
> Jan 21 16:00:26 terrorbytes kernel: Aborting journal on device md0.
> Jan 21 16:00:26 terrorbytes kernel: ext3_abort called.
> Jan 21 16:00:26 terrorbytes kernel: EXT3-fs abort (device md0):
> ext3_journal_start: Detected aborted journal
> Jan 21 16:00:26 terrorbytes kernel: Remounting filesystem read-only
> 
> 1) Can someone explain what this means, and or why it might happen?
> 2) Why this condition might exist even after a succesfull fsck?

In case it wasn't clear before (I thought it was) you are having problems
because this fs is > 2TB.  Why, I'm not sure - it may relate to LVM/MD,
it may be the block layer, or it may be an ext3 bug.  The fact that it is
at 2TB makes it seem like a block layer bug or lower.

I would start by making a backup if you haven't already.

I think debugging it would be easiest if you had a backup and were
willing to overwrite the device with a test pattern.

If you can isolate the corruptionto a single file or dir, you may get some
insight into the problem by running filefrag on it (or "stat {path}" in
debugfs.

> I am planning on running a fsck yet again.

Won't prevent problems from recurring.

> 
> Sincerely,
> Dennis Williams
> 
> On Fri, 20 Jan 2006, Dennis Williams wrote:
> 
> >
> > > > The system has now been corecting errors for the past 12 hours.  I hope
> > > > when it finishes, it will mount without complaints.
> > >
> > > Never belive fsck here. It may check heavy corrupted filesystems serval DAYS.
> > > For me (corrupted 120 Gb ext3 partition) "fsck.ext3 -y" work 3 days before i
> > > interrupt it. In manual mode, avoid 'duplicate inode clone' and answer yes to
> > > 'delete file' - only 30 minutes.
> > >
> >
> > Just out of morbid curiosity what does 'duplicate inode clone' mean?  And
> > how does the fs get in that state?
> >
> > The fsck finished this morning with the following final statements:
> >
> > /dev/md0: ***** FILE SYSTEM WAS MODIFIED *****
> >
> > /dev/md0: ********** WARNING: Filesystem still has errors **********
> >
> > /dev/md0: 1472505/403685856 files (10.3% non-contiguous),
> > 673983041/805797888 blocks
> >
> > 1) Why would the fs still have errors?  Is it correct to assume that
> > running fsck again is the answer? (I hope so)
> >
> > 2) What does the last line of this message mean?
> >
> > I did notice that the fs mounted correctly after this with the following
> > errors in /var/log/messages:
> >
> > Jan 21 02:09:48 terrorbytes kernel: kjournald starting.  Commit interval 5
> > seconds
> > Jan 21 02:09:48 terrorbytes kernel: EXT3-fs warning (device md0):
> > ext3_clear_journal_err: Filesystem error recorded from previous mount: IO
> > failure
> > Jan 21 02:09:48 terrorbytes kernel: EXT3-fs warning (device md0):
> > ext3_clear_journal_err: Marking fs in need of filesystem check.
> > Jan 21 02:09:48 terrorbytes kernel: EXT3-fs warning: mounting unchecked
> > fs, running e2fsck is recommended
> > Jan 21 02:09:48 terrorbytes kernel: EXT3 FS on md0, internal journal
> > Jan 21 02:09:48 terrorbytes kernel: EXT3-fs: mounted filesystem with
> > ordered data mode.
> >
> > after unmounting the filesystem, I ran a standard fsck again:
> > terrorbytes:~ # e2fsck /dev/md0
> > e2fsck 1.34 (25-Jul-2003)
> > /dev/md0 contains a file system with errors, check forced.
> > Pass 1: Checking inodes, blocks, and sizes
> >
> > Thank you to everyone who has responded to my posts with thier
> > suggestions.
> >
> > Sincerely,
> > Dennison Williams
> >
> > _______________________________________________
> > 
> > Ext3-users@xxxxxxxxxx
> > https://www.redhat.com/mailman/listinfo/ext3-users
> >
> 
> _______________________________________________
> 
> Ext3-users@xxxxxxxxxx
> https://www.redhat.com/mailman/listinfo/ext3-users

Cheers, Andreas
--
Andreas Dilger
Principal Software Engineer
Cluster File Systems, Inc.

_______________________________________________

Ext3-users@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/ext3-users

[Index of Archives]         [Linux RAID]     [Kernel Development]     [Red Hat Install]     [Video 4 Linux]     [Postgresql]     [Fedora]     [Gimp]     [Yosemite News]

  Powered by Linux