Invalid superblock after e2fsck
 

Hi,

e2fsck quits after the bad magic number message. I didn't pasted the
entire e2fsck output (sorry!). The full output was that:

root@pacs:~# e2fsck -C 0 -y -t /dev/storage/cabina_snapshot2
e2fsck 1.41.9 (22-Aug-2009)
/dev/storage/cabina_snapshot2 contains a file system with errors, check
forced.
Pass 1: Checking inodes, blocks, and sizes
/dev/storage/cabina_snapshot2: |================== / 60.0%

[...]

Until 60% of the progress bar, there was no error messages. After reach
the 60%, e2fsck started fixing a lot of things. In the output I
recognized the inode that it was analyzing. Once e2fsck analyzed the
last inode of the filesystem, it printed this message and exited:

Pass 1: Memory used: 268k/18014398508105072k (59k/210k), time:
65673.66/1550.92/1371.06
Pass 1: I/O read: 253456MB, write: 23885MB, rate: 4.22MB/s
Restarting e2fsck from the beginning...
e2fsck: Superblock invalid, trying backup blocks...
e2fsck: Bad magic number in super-block while trying to
open /dev/storage/cabina_snapshot

The superblock could not be read or does not describe a correct ext2
filesystem. If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate
superblock:
e2fsck -b 8193 <device>

About your questions:

The content of the default superblock (I mean the superblock located at
block 0) was correct before to launch e2fsck because I was able to mount
it and use the filesystem. (I also dumped their content and checked it).

After the filesystem check, the superblock was filled only with zeros
(no magic number, no inode counts, etc...), all the 4096 bytes at zero.


I've not tried to launch the e2fsck over a backup superblock instead of
over the default one because I think that this would produce the same
result. I'm sure that the original superblock was not corrupted then I
guess that with a backup superblock, e2fsck would have the same
behavior.

What do you think? Should I try to launch it over a backup superblock at
the first time?

Any other ideas?

Thanks you very much!


El dg 21 de 02 de 2010 a les 04:51 -0800, en/na Stephen Samuel (gmail)
va escriure:
> The system is using the backup superblock -- which sounds reasonable,
> under the circumstances, and should result in a half-decent recovery.
>
> A couple of questions:
> Was the superblock zero to begin with, or did it become zero during
> the FSCK?
> In either case, I'm worried about the zero data having been written.
> This is obviously worth further investigation.
> Did the system abort the FSCK after this error? or did you stop it?
> did you try explicitly using one of the backup superblocks?
> a list of backup superblocks can be found by using -n on mkfs
> check the -b option on fsck.ext2 for more details on the backup
> superblock defaults.
>
> 2010/2/21 Albert Sellarès <whats@wekk.net>
> Hi all,
>
> I'm trying to fix a 7.5Tb ext3 filesystem using e2fsck on a
> x86_64
> machine with plenty of memory ram. The filesystem is
> corrupted, but I
> can mount it.is
>
> Before starting the filesystem check, I did a LVM snapshot to
> be able to
> start it again from the same point in case of error.
>
> After 12 hours checking the filesystem, I got this error
> message:
>
> Pass 1: Memory used: 268k/18014398508105072k (59k/210k), time:
> 65673.66/1550.92/1371.06
> Pass 1: I/O read: 253456MB, write: 23885MB, rate: 4.22MB/s
> Restarting e2fsck from the beginning...
> e2fsck: Superblock invalid, trying backup blocks...
> e2fsck: Bad magic number in super-block while trying to
> open /dev/storage/cabina_snapshot
>
> Once I saw this message, my first thought was that e2fsck
> didn't manage
> to fix the filesystem and it corrupted the superblock. To be
> sure I
> dumped the entire block and compared it against the original
> superblock.
> Doing that I realized that the entire superblock only
> contained zeros.
>
> Any ideas of what can I do?
>
>
> --
> Stephen Samuel http://www.bcgreen.com Software, like love,
> 778-861-7641 grows when you give it away
--
Albert Sellarès GPG id: 0x13053FFE
http://www.wekk.net whats@jabber.org
Linux User: 324456
_______________________________________________
Ext3-users mailing list
Ext3-users@redhat.com
https://www.redhat.com/mailman/listinfo/ext3-users

Invalid superblock after e2fsck
 

I'm worried toat fsck is corrupting your filesystem.... That implies that something else is seriously wrong -- either the controller, the kernel or the copy of e2fsck that you're using.

At this point, I'd suggest doing the FSCK from a CD.* If you have the time to work on this, you can try an 'fsck -n' to see if you have good resuts without writing to the drive.

In the meantime, I would also verify the FSCK instance.** If you're running Red Hat, that would be an
** rpm --verify {package-name}
{package-name} is probably e2fstools, but I'm not currently on a redhat system to check that right now.** I'm not sure what the debian equivalent is.


manually starting fsck also has the advantage that the system will be more resliant to errors. It asks questions before it does things, but it will ask to fix problems that would cause an abort during a pre-mount preen.


In any case, boot from a CD,* do a system memory check (to make sure you have no bad RAM), and then manually start the FSCK.** If all of that works, then I would say that your root filesystem is corrupt.* Try using chkrootkit to see if there's a root kit installed, or just reload the OS.



2010/2/21 Albert Sellarès <whats@wekk.net>

Hi,



e2fsck quits after the bad magic number message. I didn't pasted the

entire e2fsck output (sorry!). The full output was that:



root@pacs:~# e2fsck -C 0 -y -t /dev/storage/cabina_snapshot2

e2fsck 1.41.9 (22-Aug-2009)

/dev/storage/cabina_snapshot2 contains a file system with errors, check

forced.

Pass 1: Checking inodes, blocks, and sizes

/dev/storage/cabina_snapshot2: |================== * * * * * * */ 60.0%



[...]



Until 60% of the progress bar, there was no error messages. After reach

the 60%, e2fsck started fixing a lot of things. In the output I

recognized the inode that it was analyzing. Once e2fsck analyzed the

last inode of the filesystem, it printed this message and exited:



Pass 1: Memory used: 268k/18014398508105072k (59k/210k), time:

65673.66/1550.92/1371.06

Pass 1: I/O read: 253456MB, write: 23885MB, rate: 4.22MB/s

Restarting e2fsck from the beginning...

e2fsck: Superblock invalid, trying backup blocks...

e2fsck: Bad magic number in super-block while trying to

open /dev/storage/cabina_snapshot



The superblock could not be read or does not describe a correct ext2

filesystem. *If the device is valid and it really contains an ext2

filesystem (and not swap or ufs or something else), then the superblock

is corrupt, and you might try running e2fsck with an alternate

superblock:

* *e2fsck -b 8193 <device>



About your questions:



The content of the default superblock (I mean the superblock located at

block 0) was correct before to launch e2fsck because I was able to mount

it and use the filesystem. (I also dumped their content and checked it).



After the filesystem check, the superblock was filled only with zeros

(no magic number, no inode counts, etc...), all the 4096 bytes at zero.





I've not tried to launch the e2fsck over a backup superblock instead of

over the default one because I think that this would produce the same

result. I'm sure that the original superblock was not corrupted then I

guess that with a backup superblock, e2fsck would have the same

behavior.



What do you think? Should I try to launch it over a backup superblock at

the first time?



Any other ideas?



Thanks you very much!





El dg 21 de 02 de 2010 a les 04:51 -0800, en/na Stephen Samuel (gmail)

va escriure:

> The system is using the backup superblock -- which sounds *reasonable,

> under the circumstances, and should result in a half-decent recovery.

>

> A couple of questions:

> Was the superblock zero to begin with, or did it become zero during

> the FSCK?

> In either case, I'm worried about the zero data having been written.

> This is obviously worth further investigation.

> Did the system abort the FSCK after this error? or did you stop it?

> did you try explicitly using one of the backup superblocks?

> * a list of backup superblocks can be found by using -n on mkfs

> * check the -b option on fsck.ext2 for more details on the backup

> superblock defaults.

>

> 2010/2/21 Albert Sellarès <whats@wekk.net>

> * * * * Hi all,

>

> * * * * I'm trying to fix a 7.5Tb ext3 filesystem using e2fsck on a

> * * * * x86_64

> * * * * machine with plenty of memory ram. The filesystem is

> * * * * corrupted, but I

> * * * * can mount it.is

>

> * * * * Before starting the filesystem check, I did a LVM snapshot to

> * * * * be able to

> * * * * start it again from the same point in case of error.

>

> * * * * After 12 hours checking the filesystem, I got this error

> * * * * message:

>

> * * * * Pass 1: Memory used: 268k/18014398508105072k (59k/210k), time:

> * * * * 65673.66/1550.92/1371.06

> * * * * Pass 1: I/O read: 253456MB, write: 23885MB, rate: 4.22MB/s

> * * * * Restarting e2fsck from the beginning...

> * * * * e2fsck: Superblock invalid, trying backup blocks...

> * * * * e2fsck: Bad magic number in super-block while trying to

> * * * * open /dev/storage/cabina_snapshot

>

> * * * * Once I saw this message, my first thought was that e2fsck

> * * * * didn't manage

> * * * * to fix the filesystem and it corrupted the superblock. To be

> * * * * sure I

> * * * * dumped the entire block and compared it against the original

> * * * * superblock.

> * * * * Doing that I realized that the entire superblock only

> * * * * contained zeros.

>

> * * * * Any ideas of what can I do?

>

>

> --

> Stephen Samuel http://www.bcgreen.com *Software, like love,

> 778-861-7641 * * * * * * * * * * * * * * *grows when you give it away

--

*Albert Sellarès * * * *GPG id: 0x13053FFE

*http://www.wekk.net * *whats@jabber.org

*Linux User: 324456



--
Stephen Samuel http://www.bcgreen.com *Software, like love,
778-861-7641 * * * * * * * * * * * * * * *grows when you give it away


_______________________________________________
Ext3-users mailing list
Ext3-users@redhat.com
https://www.redhat.com/mailman/listinfo/ext3-users

Invalid superblock after e2fsck
 

On 2/21/2010 3:51 AM, Albert Sellarès wrote:

Hi all,

I'm trying to fix a 7.5Tb ext3 filesystem using e2fsck on a x86_64
machine with plenty of memory ram. The filesystem is corrupted, but I
can mount it.


What partition table format are you using? I sure hope
it's not msdos. If it is your problem might be caused by
this. I once had similar problems. I was able to replace
the msdos table with a GPT table, and then use the
gparted 'rescue' command to recover without loosing
a single bit of data.

Cordially,
--
Jon Forrest
Research Computing Support
College of Chemistry
173 Tan Hall
University of California Berkeley
Berkeley, CA
94720-1460
510-643-1032
jlforrest@berkeley.edu

_______________________________________________
Ext3-users mailing list
Ext3-users@redhat.com
https://www.redhat.com/mailman/listinfo/ext3-users

Invalid superblock after e2fsck
 

Hi,

the filesystem is on a SAN device and was connected to a 32bits RHEL4
system.

To be able to check it with enough ram and with a new kernel, I
installed an ubuntu karmic on a new x86_64 machine and I plugged the SAN
to it. The new machine have 4Gb of RAM and 90Gb of SWAP.

Thinking in what you say, I think that the only thing that can be
"broken" in the new system is the hard drive because is the only part
not completely new, however, I will verify memory RAM.

By the way, today before to send the first email, I've downloaded the
last version of e2fstools (only one version upper that the ubuntu
package), I've compiled it and I've launched the filesystem check using
the new version of e2fsck. Now, the process e2fsck is at 60% and it is
using 28Gb of memory. I don't understand why the first filesystem check
(the one that I explained in the first email) didn't almost use SWAP
space. It is weird to see that there is a big difference in memory usage
between both versions.

Is it "normal"? What can be happening?

Sorry for bother you with so many questions. :(

Thanks you very much.

El dg 21 de 02 de 2010 a les 09:38 -0800, en/na Stephen Samuel (gmail)
va escriure:
> I'm worried toat fsck is corrupting your filesystem.... That implies
> that something else is seriously wrong -- either the controller, the
> kernel or the copy of e2fsck that you're using.
>
> At this point, I'd suggest doing the FSCK from a CD. If you have the
> time to work on this, you can try an 'fsck -n' to see if you have good
> resuts without writing to the drive.
> In the meantime, I would also verify the FSCK instance. If you're
> running Red Hat, that would be an
> rpm --verify {package-name}
> {package-name} is probably e2fstools, but I'm not currently on a
> redhat system to check that right now. I'm not sure what the debian
> equivalent is.
>
> manually starting fsck also has the advantage that the system will be
> more resliant to errors. It asks questions before it does things, but
> it will ask to fix problems that would cause an abort during a
> pre-mount preen.
>
> In any case, boot from a CD, do a system memory check (to make sure
> you have no bad RAM), and then manually start the FSCK. If all of
> that works, then I would say that your root filesystem is corrupt.
> Try using chkrootkit to see if there's a root kit installed, or just
> reload the OS.
>
>
> 2010/2/21 Albert Sellarès <whats@wekk.net>
> Hi,
>
> e2fsck quits after the bad magic number message. I didn't
> pasted the
> entire e2fsck output (sorry!). The full output was that:
>
> root@pacs:~# e2fsck -C 0 -y -t /dev/storage/cabina_snapshot2
> e2fsck 1.41.9 (22-Aug-2009)
> /dev/storage/cabina_snapshot2 contains a file system with
> errors, check
> forced.
> Pass 1: Checking inodes, blocks, and sizes
> /dev/storage/cabina_snapshot2: |==================
> / 60.0%
>
> [...]
>
> Until 60% of the progress bar, there was no error messages.
> After reach
> the 60%, e2fsck started fixing a lot of things. In the output
> I
> recognized the inode that it was analyzing. Once e2fsck
> analyzed the
> last inode of the filesystem, it printed this message and
> exited:
>
> Pass 1: Memory used: 268k/18014398508105072k (59k/210k), time:
> 65673.66/1550.92/1371.06
> Pass 1: I/O read: 253456MB, write: 23885MB, rate: 4.22MB/s
> Restarting e2fsck from the beginning...
> e2fsck: Superblock invalid, trying backup blocks...
> e2fsck: Bad magic number in super-block while trying to
> open /dev/storage/cabina_snapshot
>
>
> The superblock could not be read or does not describe a
> correct ext2
> filesystem. If the device is valid and it really contains an
> ext2
> filesystem (and not swap or ufs or something else), then the
> superblock
> is corrupt, and you might try running e2fsck with an alternate
> superblock:
> e2fsck -b 8193 <device>
>
> About your questions:
>
> The content of the default superblock (I mean the superblock
> located at
> block 0) was correct before to launch e2fsck because I was
> able to mount
> it and use the filesystem. (I also dumped their content and
> checked it).
>
> After the filesystem check, the superblock was filled only
> with zeros
> (no magic number, no inode counts, etc...), all the 4096 bytes
> at zero.
>
>
> I've not tried to launch the e2fsck over a backup superblock
> instead of
> over the default one because I think that this would produce
> the same
> result. I'm sure that the original superblock was not
> corrupted then I
> guess that with a backup superblock, e2fsck would have the
> same
> behavior.
>
> What do you think? Should I try to launch it over a backup
> superblock at
> the first time?
>
> Any other ideas?
>
> Thanks you very much!
>
>
> El dg 21 de 02 de 2010 a les 04:51 -0800, en/na Stephen Samuel
> (gmail)
> va escriure:
>
> > The system is using the backup superblock -- which sounds
> reasonable,
> > under the circumstances, and should result in a half-decent
> recovery.
> >
> > A couple of questions:
> > Was the superblock zero to begin with, or did it become zero
> during
> > the FSCK?
> > In either case, I'm worried about the zero data having been
> written.
> > This is obviously worth further investigation.
> > Did the system abort the FSCK after this error? or did you
> stop it?
> > did you try explicitly using one of the backup superblocks?
> > a list of backup superblocks can be found by using -n on
> mkfs
> > check the -b option on fsck.ext2 for more details on the
> backup
> > superblock defaults.
> >
> > 2010/2/21 Albert Sellarès <whats@wekk.net>
> > Hi all,
> >
> > I'm trying to fix a 7.5Tb ext3 filesystem using
> e2fsck on a
> > x86_64
> > machine with plenty of memory ram. The filesystem is
> > corrupted, but I
> > can mount it.is
> >
> > Before starting the filesystem check, I did a LVM
> snapshot to
> > be able to
> > start it again from the same point in case of error.
> >
> > After 12 hours checking the filesystem, I got this
> error
> > message:
> >
> > Pass 1: Memory used: 268k/18014398508105072k
> (59k/210k), time:
> > 65673.66/1550.92/1371.06
> > Pass 1: I/O read: 253456MB, write: 23885MB, rate:
> 4.22MB/s
> > Restarting e2fsck from the beginning...
> > e2fsck: Superblock invalid, trying backup blocks...
> > e2fsck: Bad magic number in super-block while trying
> to
> > open /dev/storage/cabina_snapshot
> >
> > Once I saw this message, my first thought was that
> e2fsck
> > didn't manage
> > to fix the filesystem and it corrupted the
> superblock. To be
> > sure I
> > dumped the entire block and compared it against the
> original
> > superblock.
> > Doing that I realized that the entire superblock
> only
> > contained zeros.
> >
> > Any ideas of what can I do?
> >
> >
> > --
> > Stephen Samuel http://www.bcgreen.com Software, like love,
> > 778-861-7641 grows when you
> give it away
>
>
> --
> Albert Sellarès GPG id: 0x13053FFE
> http://www.wekk.net whats@jabber.org
> Linux User: 324456
>
>
>
>
> --
> Stephen Samuel http://www.bcgreen.com Software, like love,
> 778-861-7641 grows when you give it away
--
Albert Sellarès GPG id: 0x13053FFE
http://www.wekk.net whats@jabber.org
Linux User: 324456
_______________________________________________
Ext3-users mailing list
Ext3-users@redhat.com
https://www.redhat.com/mailman/listinfo/ext3-users

Invalid superblock after e2fsck
 

Hi,

I'm not using any partition table, I'm directly using a Logical
Volume. :)

Greetings.

> What partition table format are you using? I sure hope
> it's not msdos. If it is your problem might be caused by
> this. I once had similar problems. I was able to replace
> the msdos table with a GPT table, and then use the
> gparted 'rescue' command to recover without loosing
> a single bit of data.
>
> Cordially,
> --
> Jon Forrest
> Research Computing Support
> College of Chemistry
> 173 Tan Hall
> University of California Berkeley
> Berkeley, CA
> 94720-1460
> 510-643-1032
> jlforrest@berkeley.edu
>
> _______________________________________________
> Ext3-users mailing list
> Ext3-users@redhat.com
> https://www.redhat.com/mailman/listinfo/ext3-users
--
Albert Sellarès GPG id: 0x13053FFE
http://www.wekk.net whats@jabber.org
Linux User: 324456
_______________________________________________
Ext3-users mailing list
Ext3-users@redhat.com
https://www.redhat.com/mailman/listinfo/ext3-users

Invalid superblock after e2fsck
 

Albert Sellarès wrote:
> Hi all,
>
> I'm trying to fix a 7.5Tb ext3 filesystem using e2fsck on a x86_64
> machine with plenty of memory ram. The filesystem is corrupted, but I
> can mount it.
>
> Before starting the filesystem check, I did a LVM snapshot to be able to
> start it again from the same point in case of error.
>
> After 12 hours checking the filesystem, I got this error message:
>
> Pass 1: Memory used: 268k/18014398508105072k (59k/210k), time:
> 65673.66/1550.92/1371.06
> Pass 1: I/O read: 253456MB, write: 23885MB, rate: 4.22MB/s
> Restarting e2fsck from the beginning...
> e2fsck: Superblock invalid, trying backup blocks...
> e2fsck: Bad magic number in super-block while trying to
> open /dev/storage/cabina_snapshot
>
> Once I saw this message, my first thought was that e2fsck didn't manage
> to fix the filesystem and it corrupted the superblock. To be sure I
> dumped the entire block and compared it against the original superblock.
> Doing that I realized that the entire superblock only contained zeros.
>
> Any ideas of what can I do?

What is the blocksize of your filesystem? RHEL4 should be safe for
2^31 blocks, which -should- get you to 8T at 4k blocks.

dumpe2fs -h info would show us (long as you have an intact superblock
somewehre...)

But if you were beyond 2^31 blocks I imagine you'd have hit troubles early on.

-Eric

_______________________________________________
Ext3-users mailing list
Ext3-users@redhat.com
https://www.redhat.com/mailman/listinfo/ext3-users

Invalid superblock after e2fsck
 

Unh, hold on...
Somebody else can hopefully answer this question:
Haven't there been problems moving an ext2 filesystem between 32bit and 64bit kernels?
If so, are all of those problems known solved, or may we have run into one here?


2010/2/21 Albert Sellarès <whats@wekk.net>

Hi,



the filesystem is on a SAN device and was connected to a 32bits RHEL4

system.



To be able to check it with enough ram and with a new kernel, I

installed an ubuntu karmic on a new x86_64 machine and I plugged the SAN

to it. The new machine have 4Gb of RAM and 90Gb of SWAP.


--
Stephen Samuel http://www.bcgreen.com *Software, like love,
778-861-7641 * * * * * * * * * * * * * * *grows when you give it away


_______________________________________________
Ext3-users mailing list
Ext3-users@redhat.com
https://www.redhat.com/mailman/listinfo/ext3-users

Invalid superblock after e2fsck
 

On Sun, Feb 21, 2010 at 03:00:15PM +0100, Albert Sellarès wrote:
>
> e2fsck quits after the bad magic number message. I didn't pasted the
> entire e2fsck output (sorry!). The full output was that:
>
> root@pacs:~# e2fsck -C 0 -y -t /dev/storage/cabina_snapshot2
> e2fsck 1.41.9 (22-Aug-2009)
> /dev/storage/cabina_snapshot2 contains a file system with errors, check
> forced.
> Pass 1: Checking inodes, blocks, and sizes
> /dev/storage/cabina_snapshot2: |================== / 60.0%
>
> [...]
>
> Until 60% of the progress bar, there was no error messages. After reach
> the 60%, e2fsck started fixing a lot of things. In the output I
> recognized the inode that it was analyzing. Once e2fsck analyzed the
> last inode of the filesystem, it printed this message and exited:

So *do* you have the full e2fsck output? I'd like to look at it to
see what it did. It's _possible_ that a really badly corrupted file
system block might have caused it to get confused enough such that it
managed to overwrite the superblock while trying to fix the
filesystem. But unless I see the whole e2fsck output, it's hard to
say for sure what happened.

- Ted

_______________________________________________
Ext3-users mailing list
Ext3-users@redhat.com
https://www.redhat.com/mailman/listinfo/ext3-users

Invalid superblock after e2fsck
 

Hi,

I have the original filesystem (on a logical volume) "intact" because I've
always worked on snapshots.

The filesystem has less than 2^31 blocks. This system has been correctly
running for four years and corruption become because of a hardware problem
with a SAN device.

The output of dumpe2fs -h /dev/storage/cabina is:

dumpe2fs 1.41.9 (22-Aug-2009)
Filesystem volume name: <none>
Last mounted on: <not available>
Filesystem UUID: 607db553-3dc2-4304-9059-37eb99f1047b
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal resize_inode filetype sparse_super
large_file
Filesystem flags: signed_directory_hash
Default mount options: (none)
Filesystem state: clean with errors
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 1038548992
Block count: 2077085696
Reserved block count: 0
Free blocks: 220295654
Free inodes: 1004004295
First block: 0
Block size: 4096
Fragment size: 4096
Reserved GDT blocks: 877
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 16384
Inode blocks per group: 512
Filesystem created: Fri Jul 7 16:45:37 2006
Last mount time: Wed Jan 20 11:53:00 2010
Last write time: Thu Feb 11 10:16:13 2010
Mount count: 65
Maximum mount count: 35
Last checked: Sat Jul 15 05:53:09 2006
Check interval: 15552000 (6 months)
Next check after: Thu Jan 11 04:53:09 2007
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 128
Journal inode: 8
Default directory hash: tea
Directory Hash Seed: 94a8b51f-6ba4-484d-bb92-167cb75c3eb6
Journal backup: inode blocks
Journal size: 32M

Thanks you!

> What is the blocksize of your filesystem? RHEL4 should be safe for
> 2^31 blocks, which -should- get you to 8T at 4k blocks.
>
> dumpe2fs -h info would show us (long as you have an intact superblock
> somewehre...)
>
> But if you were beyond 2^31 blocks I imagine you'd have hit troubles
early
> on.
>
> -Eric

--
Albert Sellarès GPG id: 0x13053FFE
http://www.wekk.net whats@jabber.org
Linux User: 324456

_______________________________________________
Ext3-users mailing list
Ext3-users@redhat.com
https://www.redhat.com/mailman/listinfo/ext3-users

Invalid superblock after e2fsck
 

Hi,

I don't have the full e2fsck output now, but I can relaunch it to produce
the same behaviour and save the output. I will do it now, then I hope to
have the full output in +12h more or less.

Thanks all for your help and interest.

> So *do* you have the full e2fsck output? I'd like to look at it to
> see what it did. It's _possible_ that a really badly corrupted file
> system block might have caused it to get confused enough such that it
> managed to overwrite the superblock while trying to fix the
> filesystem. But unless I see the whole e2fsck output, it's hard to
> say for sure what happened.
>
> - Ted

--
Albert Sellarès GPG id: 0x13053FFE
http://www.wekk.net whats@jabber.org
Linux User: 324456

_______________________________________________
Ext3-users mailing list
Ext3-users@redhat.com
https://www.redhat.com/mailman/listinfo/ext3-users