Bug#583870: inconsistencies in ext3 file systems
 

Hi Toni,

Toni Mueller wrote:
> On Mon, 31.05.2010 at 20:27:02 +0200, Toni Mueller <support@oeko.net> wrote:

>> # fsck -p /dev/mapper/uv0-srv
>> fsck 1.41.3 (12-Oct-2008)
>> /dev/mapper/uv0-srv contains a file system with errors, check forced.
>> /dev/mapper/uv0-srv: Problem in HTREE directory inode 20742394: node (5) has invalid depth (2)
>> /dev/mapper/uv0-srv: Problem in HTREE directory inode 20742394: node (5) has bad max hash
>> /dev/mapper/uv0-srv: Problem in HTREE directory inode 20742394: node (5) not referenced
>
> it turns out that only one directory was affected. This directory
> contains 488984 files. I don't think that having many files in a
> directory should be an error, only (possibly) a performance problem.
> But in no case should the file system become corrupted, imho.

Well, yes, that's clearly true. :)

Do you still have the corrupted filesystem available? It might be
interesting to try to do a post-mortem analysis on it --- please see
the RAW IMAGE FILES section of e2image(8) and let us know if that
will be possible.

Sorry for the long silence.

Thanks and hope that that helps,
Jonathan



--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20111127040653.GA12767@elie.hsd1.il.comcast.net">h ttp://lists.debian.org/20111127040653.GA12767@elie.hsd1.il.comcast.net

Bug#583870: inconsistencies in ext3 file systems
 

Hi Jonathan,

On 11/27/2011 05:06 AM, Jonathan Nieder wrote:
> Do you still have the corrupted filesystem available? It might be
> interesting to try to do a post-mortem analysis on it --- please see
> the RAW IMAGE FILES section of e2image(8) and let us know if that
> will be possible.

the file system is still available, but I need to check with the user if
I can ship his data offsite, and it would be a large file (~115GB). I
have no way to store that image on the same machine, so it needs to be
shipped elsewhere using nc or something, to begin with (iow, it could
take some time to get done).


Kind regards,
--Toni++




--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4ED3CE91.2070903@oeko.net">http://lists.debian.org/4ED3CE91.2070903@oeko.net

Bug#583870: inconsistencies in ext3 file systems
 

Toni Müller wrote:

> the file system is still available, but I need to check with the user if
> I can ship his data offsite, and it would be a large file (~115GB).

Note that "e2image -r" only writes metadata (using holes in place of
actual data), so "e2image -r <device> - | bzip2 > corrupted.e2i.bz2"
may not be too large if the metadata is not too complex. If you want
to avoid revealing filenames, the "-s" option to e2image can help.



--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20111129113649.GD1924@elie.hsd1.il.comcast.net">ht tp://lists.debian.org/20111129113649.GD1924@elie.hsd1.il.comcast.net

Bug#583870: inconsistencies in ext3 file systems
 

Jonathan Nieder wrote:

> Note that "e2image -r" only writes metadata (using holes in place of
> actual data), so "e2image -r <device> - | bzip2 > corrupted.e2i.bz2"
> may not be too large if the metadata is not too complex. If you want
> to avoid revealing filenames, the "-s" option to e2image can help.

Now that I look at the manual more closely, "e2image -Q" might be more
convenient.



--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20111129113855.GE1924@elie.hsd1.il.comcast.net">ht tp://lists.debian.org/20111129113855.GE1924@elie.hsd1.il.comcast.net

Bug#583870: inconsistencies in ext3 file systems
 

On 11/29/2011 12:38 PM, Jonathan Nieder wrote:
> Jonathan Nieder wrote:
>> Note that "e2image -r" only writes metadata (using holes in place of
>> actual data), so "e2image -r <device> - | bzip2 > corrupted.e2i.bz2"
>> may not be too large if the metadata is not too complex. If you want
>> to avoid revealing filenames, the "-s" option to e2image can help.
>
> Now that I look at the manual more closely, "e2image -Q" might be more
> convenient.

I don't see -Q mentioned in the man page. You mean, I should backport
the e2image from Wheezy (where it first seems to appear) to Etch (the
affected system)? Any gotchas that I should be aware of?

Kind regards,
--Toni++



--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4ED4C86B.3070005@oeko.net">http://lists.debian.org/4ED4C86B.3070005@oeko.net

Bug#583870: inconsistencies in ext3 file systems
 

Toni Müller wrote:

> I don't see -Q mentioned in the man page. You mean, I should backport
> the e2image from Wheezy (where it first seems to appear) to Etch (the
> affected system)? Any gotchas that I should be aware of?

Well, whatever's most convenient. (That might be to just use "-r" ---
the only advantage of "-Q" is that it avoids wasting time writing long
blocks of zeroes that act as placeholders for data, which could speed
the compressor up.)



--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20111129120039.GA4168@elie.hsd1.il.comcast.net">ht tp://lists.debian.org/20111129120039.GA4168@elie.hsd1.il.comcast.net

Bug#583870: inconsistencies in ext3 file systems
 

Toni Müller wrote:
> On 11/27/2011 05:06 AM, Jonathan Nieder wrote:

>> Do you still have the corrupted filesystem available? It might be
>> interesting to try to do a post-mortem analysis on it --- please see
>> the RAW IMAGE FILES section of e2image(8) and let us know if that
>> will be possible.
>
> the file system is still available, but I need to check with the user if
> I can ship his data offsite

Did you find out?

An image of the corrupt filesystem (without the actual files) would be
useful since it would make it possible to try to figure out what the
nature of the corruption was, which is a first step to finding the
cause of corruption.

Curious,
Jonathan



--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120404220910.GA18889@burratino">http://lists.debian.org/20120404220910.GA18889@burratino

Bug#583870: inconsistencies in ext3 file systems
 

On 04/05/2012 12:09 AM, Jonathan Nieder wrote:
> Toni Müller wrote:
>> the file system is still available, but I need to check with the user if
>> I can ship his data offsite
>
> Did you find out?

Yuck. I talked to the user, and he's fine with shipping the data, but
somehow, it has become unclear which machine is effected, and
furthermore, the user dislikes loss of operation to find out. I'll try
to talk to him again to make the data finally available.

Sorry for the delay. :((


Kind regards,
--Toni++



--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4F7CDACE.3090809@oeko.net">http://lists.debian.org/4F7CDACE.3090809@oeko.net

Bug#583870: inconsistencies in ext3 file systems
 

Toni Müller wrote:

> Yuck. I talked to the user, and he's fine with shipping the data, but
> somehow, it has become unclear which machine is effected, and
> furthermore, the user dislikes loss of operation to find out. I'll try
> to talk to him again to make the data finally available.
>
> Sorry for the delay.

Thanks, and no problem about the delay. I just wanted to get this
moving again so it's not forgotten. :)



--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120405002137.GD19575@burratino">http://lists.debian.org/20120405002137.GD19575@burratino