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

RE: Problems with ext3 fs



> -----Original Message-----
> From: Stephen C. Tweedie [mailto:sct redhat com]
> Sent: 01 March 2002 10:28
>
> Hi,
>
> On Fri, Mar 01, 2002 at 09:10:03AM +0000, John Matthews wrote:
>
> > More info for you all. I just checked dmesg (the fs tripped into ro mode
> > again last night) to get my system output and found this:
> >
> > EXT3-fs error (device md(9,8)): ext3_readdir: directory #80865
> contains a
> > hole at offset 4096
>
> On reboot, could you please run debugfs on this filesystem and send me
> the output of
>
> $ debugfs /dev/md8
> debugfs:  stat <80865>
>
> so I can see what this file looks like?  If possible, it would also be
> useful to capture the journal file on reboot so that I can see what
> has been happening on that file recently.  tune2fs -l will tell you
> what journal inode is being used (it's normally 8 if you're using an
> internal journal), and
>
> echo 'dump <8> /tmp/md9.journal.dump' | debugfs -f - /dev/md9
>

Well, I've just arrived home and been doing some testing.

I put the two questionable filesystems into ext3 mode and ran the cron.daily
routines. It tripped straight away:

EXT3-fs error (device md(9,7)): ext3_readdir: directory #199201 contains a
hole at offset 4096
Aborting journal on device md(9,7).
Remounting filesystem read-only

nijinsky:/home/jlm# debugfs /dev/md7
debugfs 1.25 (20-Sep-2001)
debugfs:  stat <199201>
Inode: 199201   Type: directory    Mode:  0755   Flags: 0x0   Generation:
624033
User:     0   Group:     0   Size: 24576
File ACL: 0    Directory ACL: 0
Links: 2   Blockcount: 40
Fragment:  Address: 0    Number: 0    Size: 0
ctime: 0x3bed25cf -- Sat Nov 10 13:04:15 2001
atime: 0x3c88096d -- Fri Mar  8 00:44:29 2002
mtime: 0x39018ad3 -- Sat Apr 22 12:19:47 2000
BLOCKS:
(0):405975, (2):10467, (3):8720, (4):10468, (5):8721
TOTAL: 5

Output of journal: I have this file - it is 5Mb gzipped so I haven't posted
it to the list. I'll mail it to Stephen directly for comment.

After reboot to single user mode:

Checking all file systems...
fsck 1.25 (20-Sep-2001)
/dev/md0: clean, 65/24096 files, 28458/96256 blocks
/dev/md6: clean, 16/73440 files, 22368/292672 blocks
/dev/md7: recovering journal
/dev/md7 contains a file system with errors, check forced.
/dev/md7:
Directory inode 199201 has an unallocated block #1.

/dev/md7: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
        (i.e., without -a or -p options)

(none):~# fsck /dev/md7
fsck 1.25 (20-Sep-2001)
e2fsck 1.25 (20-Sep-2001)
/dev/md7 contains a file system with errors, check forced.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Directory inode 199201 has an unallocated block #1.  Allocate<y>? yes

Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Free blocks count wrong for group #0 (6070, counted=6069).
Fix<y>? yes

Free blocks count wrong (133801, counted=133800).
Fix<y>? yes


/dev/md7: ***** FILE SYSTEM WAS MODIFIED *****
/dev/md7: 82182/244320 files (1.3% non-contiguous), 354424/488224 blocks






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