Re: Crash in 2.6.28.7 - ext4 related

[Fabio Comolli <fabio.comolli@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1781 bytes --]

Hi.

On Thu, Feb 26, 2009 at 5:08 PM, Theodore Tso <tytso@mit.edu> wrote:
> I got the crash image.  Unfortunately the beginning of the Oops
> message was cut off, which might have been valuable.  There are some
> new patches that are newer than what has been backported to 2.6.28.7;
> some of them are in the for-stable branch of the ext4 git tree, and
> have been queued for 2.6.28.8.  The call stack doesn't look like one
> of the known bugs, though.
>
> Hmm... can you send us the output of dumpe2fs on the filesystem?

Attached.

> And something that would be very useful would be a raw e2image of the
> filesystem, created thusly:
>
>            e2image -r /dev/sdXXX - | bzip2 > sdXXX.e2i.bz2
>
> This image will contain the basic filesystem metadata, including the
> directory blocks (and directory names), but none of the data blocks.
> It is therefore much smaller, and if you are willing to let me see
> your directory file names, I can take that image and try to replicate
> the problem on one of my systems.

It's my home directory and so I prefer not to share, sorry. Anyway, it
seems that after the removal of that (possibly corrupted) directory, I
can't reproduce the problem anymore. I tried to create / modify /
delete some big directories, even two or three at a time with no luck.

I would post some new pictures if the problems represents.

> If you have a spare 20gb of disk space, you can also unpack the raw
> image dump and try reproducing the problem on the raw image dump.  If
> you can trigger it easily with an rm -rf operation, it should be just
> as reproducible on the raw image dump.
>
> Regards,
>
>                                                - Ted
>

Thanks,
Fabio

[-- Attachment #2: dumpe2fs.log.gz --]
[-- Type: application/x-gzip, Size: 143271 bytes --]