linux-ext4 - Re: debugfs fill

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20070411225237.GH5967@schatzie.adilger.int>
Date:	Wed, 11 Apr 2007 16:52:37 -0600
From:	Andreas Dilger <adilger@...sterfs.com>
To:	Eric Sandeen <sandeen@...hat.com>
Cc:	ext4 development <linux-ext4@...r.kernel.org>
Subject: Re: debugfs fill_bgs command?

On Apr 11, 2007  15:17 -0500, Eric Sandeen wrote:
> I was wondering if others think it would be useful to have a "fill_bgs"
> command in debugfs; this would (minimally) mark the lower X bgs as full
> for both inodes & blocks (possibly either/or), to allow testing the
> higher block groups.  I'm using a hacked up version of this to do a
> little ext3 testing above 8T.  Given that this would really only be a
> testing option in nature, would it be accepted into e2fsprogs?  I'd
> probably need some sort of "unfill" command as well, to put the bg
> counters back where they should be; probably by actually reading the
> bitmaps.  This way fsck would still find a consistent filesystem...
> 
> I had originally written a set_bg_field function too, to go with inode &
> sb variants, though for marking the first few thousand bg's it was going
> to get a bit tedious... :)

Try "mke2fs -O lazy_bg XXX" and be happy.  Can be used on any kernel as
it is a COMPAT feature and marks all but first and last groups as full.

Cheers, Andreas
--
Andreas Dilger
Principal Software Engineer
Cluster File Systems, Inc.

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