linux-ext4 - Re: [PATCH] fix up lazy_bg bitmap initialization at mkfs time

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: <20070420101020.GQ5967@schatzie.adilger.int>
Date:	Fri, 20 Apr 2007 04:10:20 -0600
From:	Andreas Dilger <adilger@...sterfs.com>
To:	Eric Sandeen <sandeen@...hat.com>
Cc:	ext4 development <linux-ext4@...r.kernel.org>
Subject: Re: [PATCH] fix up lazy_bg bitmap initialization at mkfs time

On Apr 19, 2007  16:07 -0500, Eric Sandeen wrote:
> While trying out the -O lazy_bg option, I ran into some trouble on my
> big filesystem.  The journal size was > free blocks in the first block group,
> so it spilled into the next bg with available blocks.  Since we are using
> lazy_bg here, that -should- have been the last block group.

Just as an FYI - it probably makes little sense to have a 128MB journal
for a filesystem you want to use for testing, since it would still write
128MB to your loopback device when zeroing the journal.  It still makes
sense for mke2fs and libext2fs to be fixed for correctness, but I think
it also makes sense for lazy_bg to influence the journal size.

> Unfortunately it also increases mkfs time a bit, as it must search
> a huge string of unavailable blocks if it has to allocate in the 
> last bg.  Ah well...

It also probably makes sense for libext2fs to check group descriptors
while allocating...

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