linux-ext4 - Re: [PATCH] libext2: clear BG_BLOCK_UNINIT in any group containing metadata

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] [day] [month] [year] [list]

Message-ID: <4F732E09.2000008@redhat.com>
Date:	Wed, 28 Mar 2012 10:28:09 -0500
From:	Eric Sandeen <sandeen@...hat.com>
To:	"Ted Ts'o" <tytso@....edu>
CC:	ext4 development <linux-ext4@...r.kernel.org>,
	Lukáš Czerner 
	<lczerner@...hat.com>
Subject: Re: [PATCH] libext2: clear BG_BLOCK_UNINIT in any group containing
 metadata

On 3/27/12 5:40 PM, Ted Ts'o wrote:
> On Thu, Feb 23, 2012 at 12:20:15PM -0600, Eric Sandeen wrote:
>> Running a test like the m_uninit test runs:
>>
>> # mke2fs -F -o Linux -O uninit_bg testfs 131072
>>
>> results in groups which have blocks allocated for metadata, but
>> which still have the BLOCK_UNINIT flag set:
>>
>> Group 2: (Blocks 16385-24576) [INODE_UNINIT, BLOCK_UNINIT, ITABLE_ZEROED]
>>   Checksum 0x17c2, unused inodes 2048
>>   Block bitmap at 16385 (+0), Inode bitmap at 16386 (+1)
>>   Inode table at 16387-16642 (+2)
> 
> Sorry for the delay in getting back to you.  The general rule here is
> what triggers BLOCK_UNINIT getting cleared is when we allocate
> metadata blocks for *another* block group in that block group.  When
> we initialize an uninitialized block group, it's easy enough to set
> the bits for the block group's allocation bitmaps and inode tables.
> 
> However, we *don't* want to have to scan all of the block groups to
> see if they have metadata blocks appearing in a particular block
> group, so that's the reason for this rule.
> 
> So in the above dumpe2fs output, since we aren't using flex_bg, the
> only metadata blocks which are in a bg is the bg's own metadata
> blocks, and so that's why it's OK for BLOCK_UNINIT to be set.  This
> isn't a bug.

Hrm, ok, thanks for looking at it.

FWIW, this still fails:

dd if=/dev/zero of=fsfile bs=1M count=128
losetup /dev/loop0 fsfile
mkfs.ext4 -I 256 -b 4096 -N 256 -G 1 -g 256 /dev/loop0 1024
mount /dev/loop0 /mnt/test
mkdir /mnt/test/dir
umount /mnt/test
fsck.ext4 -fn /dev/loop0

with:

Free blocks count wrong for group #2 (253, counted=249).
Fix? no

so will have to look further at what's going on I guess.

-Eric

 
> 					- Ted

--
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