osdir.com
mailing list archive F.A.Q. -since 2001!



Subject: Re: Group descriptor 0 checksum is invalid -
msg#00248

List: linux-ext4

Mail Archive Navigation:
by Date: Prev Next Date Index by Thread: Prev Next Thread Index

On 2009-11-14, at 14:00, Christian Kujau wrote:
when trying to convert an ext3 filesystem to ext4, I'm getting these
"Group descriptor 0 checksum is invalid" messages. I've seen them before
and the net is full of them, but I still wonder if they're expected to
show up at all during the filesystem's first fsck. See below for the
script log.

Yes, this is because enabling the uninit_bg feature on the filesystem also
requires that the group descriptor checksums are used. This is the reason
why it asks you to run e2fsck on the filesystem.

It isn't safe to just have tune2fs initialize the unused inode count based
on the inode bitmap and then compute the checksums when the uninit_bg
feature, since tune2fs can't know for sure know which inodes are in use
without a full e2fsck run.

I suppose it would be possible to just set the bg_itable_unused = 0 and
then compute the checksum at tune2fs, and the next time the e2fsck is
run it will initialize bg_itable_unused to the right value. It is a bit
sub-optimal, but not harmful and it avoids the need to run a full e2fsck.

sid:~# cat /proc/version
Linux version 2.6.32-rc7 (dummy@sid) (gcc version 4.4.2 (Debian 4.4.2-2) ) #1 SMP Sat Nov 14 22:00:51 CET 2009
sid:~# mkfs.ext3 -q /dev/xvdc
sid:~# mount -t ext3 /dev/xvdc /mnt/d2
sid:~# grep /dev/xvdc /proc/mounts
/dev/xvdc /mnt/d2 ext3 rw,relatime,errors=continue,data=writeback 0 0
sid:~# df -h /dev/xvdc
Filesystem Size Used Avail Use% Mounted on
/dev/xvdc 16G 173M 15G 2% /mnt/d2
sid:~# umount /dev/xvdc
sid:~# tune2fs -O extents,uninit_bg /dev/xvdc
tune2fs 1.41.9 (22-Aug-2009)

Please run e2fsck on the filesystem.

sid:~# tune2fs -l /dev/xvdc | grep -i feat
Filesystem features: has_journal ext_attr resize_inode dir_index filetype extent sparse_super large_file uninit_bg

sid:~# e2fsck -fpDC0 /dev/xvdc
/dev/xvdc: One or more block group descriptor checksums are invalid. FIXED.
/dev/xvdc: Group descriptor 0 checksum is invalid.

/dev/xvdc: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
(i.e., without -a or -p options)

sid:~# e2fsck -fDC0 /dev/xvdc
e2fsck 1.41.9 (22-Aug-2009)
One or more block group descriptor checksums are invalid. Fix<y>? yes

Group descriptor 0 checksum is invalid. FIXED.
Group descriptor 1 checksum is invalid. FIXED.
[...]
Group descriptor 126 checksum is invalid. FIXED.
Group descriptor 127 checksum is invalid. FIXED.
Pass 1: Checking inodes, blocks, and sizes
/dev/xvdc: | [...]
Pass 3: Checking directory connectivity
Pass 3A: Optimizing directories
Rebuilding directory: |================ / 50.0% [...]
Pass 5: Checking group summary information
/dev/xvdc: | ========================================================| 100.0%
/dev/xvdc: ***** FILE SYSTEM WAS MODIFIED *****
/dev/xvdc: 11/1048576 files (0.0% non-contiguous), 109874/4194304 blocks
sid:~#
sid:~# e2fsck -fC0 /dev/xvdc
/dev/xvdc: | [...]
/dev/xvdc: 11/1048576 files (0.0% non-contiguous), 109874/4194304 blocks

--
BOFH excuse #389:

/dev/clue was linked to /dev/null
--
To unsubscribe from this list: send the line "unsubscribe linux- ext4" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html


Cheers, Andreas
--
Andreas Dilger
Sr. Staff Engineer, Lustre Group
Sun Microsystems of Canada, Inc.

--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html

Thread at a glance:

Previous Message by Date:

[Bug 14602] JBD2 journal abort / checkpoint creation racy?

http://bugzilla.kernel.org/show_bug.cgi?id=14602 --- Comment #2 from Andi Kleen <andi-bz@xxxxxxxxxxxxxx> 2009-11-16 16:04:33 --- Hmm, it still seems strange because sometimes the error happens and more often not, even when triggering the same underlying inode IO error. I think something is at least inconsistent. -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching the assignee of the bug. -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html

Next Message by Date:

Re: Ext4 on SSD Intel X25-M

On Sun, Nov 15, 2009 at 05:11:46PM -0500, Theodore Tso wrote: > If you've only had the disk for a short while, then the initial writes > to install your system is probably biasing your results. So far you > have approximately 19GB of disk writes. I'm guessing that at least > 3-4GB is from the initial installation of software on your system. I just did a default Ubuntu Karmic x86_64 install, and it writes a approximately ten and a half GB to the root partition. It also (for no explicable reason) apparently zero's out the swap partition, which (a) takes a long time, and (b) results in useless, pointless writes to the SSD. Someone should complain to Ubuntu about that... the workaround is to not configure swap during the Ubuntu install process, and to manually configure it yourself later. (Or to not use swap at all, if you have enough memory in your system.) In any case, given that means that only 8.5GB worth of data was written to your system, so over 30 days, your usage levels is averaging to 0.283 GB per calendar day. - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html

Previous Message by Thread:

Re: Group descriptor 0 checksum is invalid

On Sun, 15 Nov 2009 at 22:11, Theodore Tso wrote: > Yes, it's expected. We may try to make tune2fs better about fixing up > the checksums when enabling uninit_bg at some point in the future, but > for now, it's one of the reasons why tune2fs requests that you run > e2fsck on the file system. Thanks for your reply, Ted. As the messages look rather troubling, I've documented this effect in the Wiki. Thanks, Christian. -- BOFH excuse #411: Traffic jam on the Information Superhighway. -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html

Next Message by Thread:

Re: [PATCH 2/4] ext4: Avoid issuing barriers on error recovery path

On Tue, Oct 27, 2009 at 01:48:47PM +0100, Jan Kara wrote: > There is no reason why we should issue IO barriers when we > just hit an error in ext4_sync_file. So move out: label to > just return and introduce flush: label to those places which > really need it. > > Signed-off-by: Jan Kara <jack@xxxxxxx> Once the out: label is moved to just before the "return ret;", it's actually cleaner to simply replace all of the "goto out" with "return ret;" statements..... - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
blog comments powered by Disqus

Home | News | Sitemap | FAQ | advertise | OSDir is an Inevitable website. GBiz is too!