linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* BUG EXT3-fs: fragsize 1024 != blocksize 4096 (unsupported)
       [not found] <d2be449a1003160554w2309064dj5c9e5dd5994ce23d@mail.gmail.com>
@ 2010-03-16 13:05 ` Oscar Megia
  2010-03-17 16:24   ` Jan Kara
  0 siblings, 1 reply; 6+ messages in thread
From: Oscar Megia @ 2010-03-16 13:05 UTC (permalink / raw)
  To: linux-fsdevel

Hi everyone!

Since three days ago mi PC with Fedora 9 started to do random resets.

I started to change the BIOS configuration and one of this changes
leaved the screen
black. Unfortunately, I pressed the reset button thinking that didn't
boot but the next time (after
leave the BIOS configuration like before) the system didn't boot.

It showed me this message: "EXT3-fs: fragsize 1024 != blocksize 4096
(unsupported)" (you can see two pictures booting with this error at
http://forums.fedoraforum.org/attachment.php?attachmentid=19240&d=1268739264
and http://forums.fedoraforum.org/attachment.php?attachmentid=19239&d=1268739254).

Researching I could get info from the root fs with dumpe2fs:

# losetup -r -o 196608 /dev/loop0 /dev/hda2

# dumpe2fs /dev/loop0

Filesystem volume name:   Fedoraiv-Live-i6
Last mounted on:          <not available>
Filesystem UUID:          15035e8e-1503-7c55-ba46-bfdd46659fa5
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      imagic_inodes filetype sparse_super large_file
Filesystem flags:         signed_directory_hash
Default mount options:    (none)
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              4808704
Block count:              19210240
Reserved block count:     1507328
Free blocks:              1539180
Free inodes:              4390912
First block:              0
Block size:               4096
Fragment size:            1024
Reserved GDT blocks:      251
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         56884
Inode blocks per group:   3556
Filesystem created:       Thu Jan  1 06:23:12 1970
Last mount time:          Sat Mar 13 18:49:24 2010
Last write time:          Sat Mar 13 19:55:08 2010
Mount count:              59152
Maximum mount count:      -1
Last checked:             Thu May  8 01:48:09 2008
Check interval:           0 (<none>)
Reserved blocks uid:      11 (user unknown)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:              256
Required extra isize:     1
Journal UUID:             00000000-0000-0000-0000-000008000000
Journal inode:            8
First orphan inode:       52113
Default directory hash:   tea
Directory Hash Seed:      91cb4d10-e684-4c10-5e73-e3e95e737bdc
Journal backup:           inode blocks

...

The disk has two partitions:

kdemar@kademar:~$ fdisk -l

Disk /dev/hda: 80.0 GB, 80026361856 bytes
255 heads, 63 sectors/track, 9729 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0xb838b838

   Device Boot      Start         End      Blocks   Id  System
/dev/hda1   *           1          25      200781   83  Linux
/dev/hda2              26        9729    77947380   8e  Linux LVM


hda1 is for boot and hda2/lvm/ext3 with the OS and  data. If the ext3
has journal, is this a bug in the ext3 journal filesystem?

My question is how can repair this lvm/ext3 volume without loose data?

Regards
Oscar

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: BUG EXT3-fs: fragsize 1024 != blocksize 4096 (unsupported)
  2010-03-16 13:05 ` BUG EXT3-fs: fragsize 1024 != blocksize 4096 (unsupported) Oscar Megia
@ 2010-03-17 16:24   ` Jan Kara
  2010-04-06 19:35     ` Oscar Megia
  0 siblings, 1 reply; 6+ messages in thread
From: Jan Kara @ 2010-03-17 16:24 UTC (permalink / raw)
  To: Oscar Megia; +Cc: linux-fsdevel

  Hi,

On Tue 16-03-10 13:05:09, Oscar Megia wrote:
> Since three days ago mi PC with Fedora 9 started to do random resets.
> 
> I started to change the BIOS configuration and one of this changes leaved
> the screen black. Unfortunately, I pressed the reset button thinking that
> didn't boot but the next time (after leave the BIOS configuration like
> before) the system didn't boot.
  I'd check your HW - memory, power supply, ... Obviously something got
wrong.

> It showed me this message: "EXT3-fs: fragsize 1024 != blocksize 4096
> (unsupported)" (you can see two pictures booting with this error at
> http://forums.fedoraforum.org/attachment.php?attachmentid=19240&d=1268739264
> and http://forums.fedoraforum.org/attachment.php?attachmentid=19239&d=1268739254).
> 
> Researching I could get info from the root fs with dumpe2fs:
...
> 
> hda1 is for boot and hda2/lvm/ext3 with the OS and  data. If the ext3
> has journal, is this a bug in the ext3 journal filesystem?
  I'd say it is a faulty HW, not a software bug.

> My question is how can repair this lvm/ext3 volume without loose data?
  I would first try to identify faulty HW (run memtest from a rescue CD
for example). When HW gets fixed, I'd copy the filesystem with 'dd' to a
different disk as a backup. Then run e2fsck to fix /dev/hda2.

								Honza
-- 
Jan Kara <jack@suse.cz>
SUSE Labs, CR
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: BUG EXT3-fs: fragsize 1024 != blocksize 4096 (unsupported)
  2010-03-17 16:24   ` Jan Kara
@ 2010-04-06 19:35     ` Oscar Megia
  2010-04-06 20:05       ` Jan Kara
  0 siblings, 1 reply; 6+ messages in thread
From: Oscar Megia @ 2010-04-06 19:35 UTC (permalink / raw)
  To: Jan Kara; +Cc: linux-fsdevel

Yes, it was a problem with the ATX power supply. I replaced it and now
is working fine.

I did what you told and I recover my important data but not all fs.

The matter is if you have a hardware fault the ext3 journal fs don't
preserve your data.

I'm not an expert about the journal ext3 fs but I though is designed
to preserve data so if the HD has a fault, ext3 must preserve your
data. If the fault is during updating the main fs it must go to the
previous main fs. This could happen when there is a power cut.

Regards
Oscar.

2010/3/17 Jan Kara <jack@suse.cz>:
>  Hi,
>
> On Tue 16-03-10 13:05:09, Oscar Megia wrote:
>> Since three days ago mi PC with Fedora 9 started to do random resets.
>>
>> I started to change the BIOS configuration and one of this changes leaved
>> the screen black. Unfortunately, I pressed the reset button thinking that
>> didn't boot but the next time (after leave the BIOS configuration like
>> before) the system didn't boot.
>  I'd check your HW - memory, power supply, ... Obviously something got
> wrong.
>
>> It showed me this message: "EXT3-fs: fragsize 1024 != blocksize 4096
>> (unsupported)" (you can see two pictures booting with this error at
>> http://forums.fedoraforum.org/attachment.php?attachmentid=19240&d=1268739264
>> and http://forums.fedoraforum.org/attachment.php?attachmentid=19239&d=1268739254).
>>
>> Researching I could get info from the root fs with dumpe2fs:
> ...
>>
>> hda1 is for boot and hda2/lvm/ext3 with the OS and  data. If the ext3
>> has journal, is this a bug in the ext3 journal filesystem?
>  I'd say it is a faulty HW, not a software bug.
>
>> My question is how can repair this lvm/ext3 volume without loose data?
>  I would first try to identify faulty HW (run memtest from a rescue CD
> for example). When HW gets fixed, I'd copy the filesystem with 'dd' to a
> different disk as a backup. Then run e2fsck to fix /dev/hda2.
>
>                                                                Honza
> --
> Jan Kara <jack@suse.cz>
> SUSE Labs, CR
>
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: BUG EXT3-fs: fragsize 1024 != blocksize 4096 (unsupported)
  2010-04-06 19:35     ` Oscar Megia
@ 2010-04-06 20:05       ` Jan Kara
  2010-04-06 20:16         ` Oscar Megia
  2010-04-06 21:07         ` tytso
  0 siblings, 2 replies; 6+ messages in thread
From: Jan Kara @ 2010-04-06 20:05 UTC (permalink / raw)
  To: Oscar Megia; +Cc: Jan Kara, linux-fsdevel

On Tue 06-04-10 21:35:09, Oscar Megia wrote:
> Yes, it was a problem with the ATX power supply. I replaced it and now
> is working fine.
> 
> I did what you told and I recover my important data but not all fs.
> 
> The matter is if you have a hardware fault the ext3 journal fs don't
> preserve your data.
> 
> I'm not an expert about the journal ext3 fs but I though is designed
> to preserve data so if the HD has a fault, ext3 must preserve your
> data. If the fault is during updating the main fs it must go to the
> previous main fs. This could happen when there is a power cut.
  Ext3 journal prevents filesystem corruption only in case the power
fails suddently. Also cases like kernel crashes are usually solved by the
journal quite fine. But in situations like flaky power supply where memory
can provide wrong data to disk or disk writes only some data because of
weak voltage, journaling does not help at all. Generally, only good backups
are a solution to bugs in HW...

									Honza
> 2010/3/17 Jan Kara <jack@suse.cz>:
> >  Hi,
> >
> > On Tue 16-03-10 13:05:09, Oscar Megia wrote:
> >> Since three days ago mi PC with Fedora 9 started to do random resets.
> >>
> >> I started to change the BIOS configuration and one of this changes leaved
> >> the screen black. Unfortunately, I pressed the reset button thinking that
> >> didn't boot but the next time (after leave the BIOS configuration like
> >> before) the system didn't boot.
> >  I'd check your HW - memory, power supply, ... Obviously something got
> > wrong.
> >
> >> It showed me this message: "EXT3-fs: fragsize 1024 != blocksize 4096
> >> (unsupported)" (you can see two pictures booting with this error at
> >> http://forums.fedoraforum.org/attachment.php?attachmentid=19240&d=1268739264
> >> and http://forums.fedoraforum.org/attachment.php?attachmentid=19239&d=1268739254).
> >>
> >> Researching I could get info from the root fs with dumpe2fs:
> > ...
> >>
> >> hda1 is for boot and hda2/lvm/ext3 with the OS and  data. If the ext3
> >> has journal, is this a bug in the ext3 journal filesystem?
> >  I'd say it is a faulty HW, not a software bug.
> >
> >> My question is how can repair this lvm/ext3 volume without loose data?
> >  I would first try to identify faulty HW (run memtest from a rescue CD
> > for example). When HW gets fixed, I'd copy the filesystem with 'dd' to a
> > different disk as a backup. Then run e2fsck to fix /dev/hda2.
> >
> >                                                                Honza
> > --
> > Jan Kara <jack@suse.cz>
> > SUSE Labs, CR
> >
-- 
Jan Kara <jack@suse.cz>
SUSE Labs, CR
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: BUG EXT3-fs: fragsize 1024 != blocksize 4096 (unsupported)
  2010-04-06 20:05       ` Jan Kara
@ 2010-04-06 20:16         ` Oscar Megia
  2010-04-06 21:07         ` tytso
  1 sibling, 0 replies; 6+ messages in thread
From: Oscar Megia @ 2010-04-06 20:16 UTC (permalink / raw)
  To: Jan Kara; +Cc: linux-fsdevel

I agree.

My problem was flaky power supply.

Is good to know it.

Thanks for your time,
Oscar

2010/4/6 Jan Kara <jack@suse.cz>:
> On Tue 06-04-10 21:35:09, Oscar Megia wrote:
>> Yes, it was a problem with the ATX power supply. I replaced it and now
>> is working fine.
>>
>> I did what you told and I recover my important data but not all fs.
>>
>> The matter is if you have a hardware fault the ext3 journal fs don't
>> preserve your data.
>>
>> I'm not an expert about the journal ext3 fs but I though is designed
>> to preserve data so if the HD has a fault, ext3 must preserve your
>> data. If the fault is during updating the main fs it must go to the
>> previous main fs. This could happen when there is a power cut.
>  Ext3 journal prevents filesystem corruption only in case the power
> fails suddently. Also cases like kernel crashes are usually solved by the
> journal quite fine. But in situations like flaky power supply where memory
> can provide wrong data to disk or disk writes only some data because of
> weak voltage, journaling does not help at all. Generally, only good backups
> are a solution to bugs in HW...
>
>                                                                        Honza
>> 2010/3/17 Jan Kara <jack@suse.cz>:
>> >  Hi,
>> >
>> > On Tue 16-03-10 13:05:09, Oscar Megia wrote:
>> >> Since three days ago mi PC with Fedora 9 started to do random resets.
>> >>
>> >> I started to change the BIOS configuration and one of this changes leaved
>> >> the screen black. Unfortunately, I pressed the reset button thinking that
>> >> didn't boot but the next time (after leave the BIOS configuration like
>> >> before) the system didn't boot.
>> >  I'd check your HW - memory, power supply, ... Obviously something got
>> > wrong.
>> >
>> >> It showed me this message: "EXT3-fs: fragsize 1024 != blocksize 4096
>> >> (unsupported)" (you can see two pictures booting with this error at
>> >> http://forums.fedoraforum.org/attachment.php?attachmentid=19240&d=1268739264
>> >> and http://forums.fedoraforum.org/attachment.php?attachmentid=19239&d=1268739254).
>> >>
>> >> Researching I could get info from the root fs with dumpe2fs:
>> > ...
>> >>
>> >> hda1 is for boot and hda2/lvm/ext3 with the OS and  data. If the ext3
>> >> has journal, is this a bug in the ext3 journal filesystem?
>> >  I'd say it is a faulty HW, not a software bug.
>> >
>> >> My question is how can repair this lvm/ext3 volume without loose data?
>> >  I would first try to identify faulty HW (run memtest from a rescue CD
>> > for example). When HW gets fixed, I'd copy the filesystem with 'dd' to a
>> > different disk as a backup. Then run e2fsck to fix /dev/hda2.
>> >
>> >                                                                Honza
>> > --
>> > Jan Kara <jack@suse.cz>
>> > SUSE Labs, CR
>> >
> --
> Jan Kara <jack@suse.cz>
> SUSE Labs, CR
>
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: BUG EXT3-fs: fragsize 1024 != blocksize 4096 (unsupported)
  2010-04-06 20:05       ` Jan Kara
  2010-04-06 20:16         ` Oscar Megia
@ 2010-04-06 21:07         ` tytso
  1 sibling, 0 replies; 6+ messages in thread
From: tytso @ 2010-04-06 21:07 UTC (permalink / raw)
  To: Jan Kara; +Cc: Oscar Megia, linux-fsdevel

On Tue, Apr 06, 2010 at 10:05:52PM +0200, Jan Kara wrote:
> On Tue 06-04-10 21:35:09, Oscar Megia wrote:
> > Yes, it was a problem with the ATX power supply. I replaced it and now
> > is working fine.
> > 
> > I did what you told and I recover my important data but not all fs.
> > 
> > The matter is if you have a hardware fault the ext3 journal fs don't
> > preserve your data.
> > 
> > I'm not an expert about the journal ext3 fs but I though is designed
> > to preserve data so if the HD has a fault, ext3 must preserve your
> > data. If the fault is during updating the main fs it must go to the
> > previous main fs. This could happen when there is a power cut.
>   Ext3 journal prevents filesystem corruption only in case the power
> fails suddently. Also cases like kernel crashes are usually solved by the
> journal quite fine. But in situations like flaky power supply where memory
> can provide wrong data to disk or disk writes only some data because of
> weak voltage, journaling does not help at all. Generally, only good backups
> are a solution to bugs in HW...

This is all true.  However, e2fsck should have been able to use a
duplicate superblock, and fix at least the fragsize 1024 != blocksize
4096 problem.  Depending on how much damage was done to the disk by
the flaky power supply, you might not recover all of your data, but
usually e2fsck can help you recover at least some of your files....

You might have to run it from a rescue CD if your root filesystem is
badly scrambled, though.

	       	   	    	       - Ted

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2010-04-06 21:07 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
     [not found] <d2be449a1003160554w2309064dj5c9e5dd5994ce23d@mail.gmail.com>
2010-03-16 13:05 ` BUG EXT3-fs: fragsize 1024 != blocksize 4096 (unsupported) Oscar Megia
2010-03-17 16:24   ` Jan Kara
2010-04-06 19:35     ` Oscar Megia
2010-04-06 20:05       ` Jan Kara
2010-04-06 20:16         ` Oscar Megia
2010-04-06 21:07         ` tytso

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).