As a followup, i located the directory and found it's size not 4096. After
removing it and recreating _and_ stashing it with files that were
previously there (i even tar'ed them and restrored from archive), the
directory size went wrong again. fsck until it runs clean?
--
Yay! I've got a flying machine! (UNIX)
konrads@emicovero.com
Sent by: ext3-users-admin@redhat.com
2003.07.25 11:52
To: "Christopher Li" <chrisl@vmware.com>
cc: ext3-users@redhat.com
Subject: RE: filesystem broken / bad entry in directory #248447030
Heh, i found a very minor bug:
error_msg = "rec_len % 4 != 0"; is the assignment, while "rec_len %% 4 !=
0" is printed :)
I do not really understand your conclusion magic: how come that You make
from an inode number (0x2020200a) something related with a name ' \n' in
our case. Same applies for record length. I am quite puzzled and I would
appreciate if you could explain/point to documentation
--
Yay! I've got a flying machine! (UNIX)
"Christopher Li" <chrisl@vmware.com>
2003.07.25 02:22
To: <konrads@emicovero.com>, <ext3-users@redhat.com>
cc:
Subject: RE: filesystem broken / bad entry in directory
#248447030
It seems that you have a normal file been mark as directory.
538976266 = 0x2020200a, that is a new line plugs three space.
14637 = 0x392d = '-','9'. Looks like a text file to me.
#248447030 is the inode number of the directory, which is
really big. "find . -inum 248447030" should locate the
parent directory which contain the entry for this directory.
Chris
> -----Original Message-----
> From: konrads@emicovero.com [mailto:konrads@emicovero.com]
> Sent: Thursday, July 24, 2003 3:51 PM
> To: ext3-users@redhat.com
> Subject: filesystem broken / bad entry in directory #248447030
>
>
> Jul 25 01:41:21 big kernel: EXT3-fs error (device
> device-mapper(254,16)):
> ext3_readdir: bad entry in directory #248447030: rec_len %% 4 != 0 -
> offset=0, inode=538976266, rec_len=14637, name_len=49
> Jul 25 01:42:53 big kernel: EXT3-fs error (device
> device-mapper(254,16)):
> ext3_readdir: bad entry in directory #248447030: rec_len %% 4 != 0 -
> offset=0, inode=538976266, rec_len=14637, name_len=49
>
> these entries are in the logfile.
>
> fsck does not fix them (ran multiple times).
> When going trough fs via find, it shows multiple i/o errors.
> Even file in
> root of the filesystem displays an i/o error.
>
> My idea was that if i could locate the mystical directory
> #248447030 , i
> could erase it/recreate it and be happy
> a) how do i locate
> b) what do i do now :)
>
> --
> Yay! I've got a flying machine! (UNIX)
>
>
> _______________________________________________
>
> Ext3-users@redhat.com
> https://www.redhat.com/mailman/listinfo/ext3-users
>
>
_______________________________________________
Ext3-users@redhat.com
https://www.redhat.com/mailman/listinfo/ext3-users
_______________________________________________
Ext3-users@redhat.com
https://www.redhat.com/mailman/listinfo/ext3-users
