linux-ext4 - Re: flex_bg information initialization and question on resize/bad inodes with 48 bits filesystem

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: <20090911183540.GB28764@mit.edu>
Date:	Fri, 11 Sep 2009 14:35:40 -0400
From:	Theodore Tso <tytso@....edu>
To:	Damien Guibouret <damien.guibouret@...tition-saving.com>
Cc:	linux-ext4@...r.kernel.org
Subject: Re: flex_bg information initialization and question on resize/bad
	inodes with 48 bits filesystem

On Fri, Sep 11, 2009 at 07:57:00PM +0200, Damien Guibouret wrote:
>
> I have looked at the new features provided by ext4 and have a question  
> on flex_bg information initialization:
> into ext4_fill_flex_info function of fs/ext4/super.c (lines 1698, 1700  
> and 1702 for kernel 2.6.31) doesn't the atomic_set calls be atomic_add  
> to sum statistics of each group composing a flex group, or do I  
> misunderstand something ?

Good eye; that's a bug; thanks for pointing that out.

> For the extension to manage 48 bits blocks number, I do not see anything  
> to treat this for resize and bad inodes into kernel or e2fsprogs. For  
> the resize inode, it is perhaps an incompatibility of this feature with  
> 48 bits blocks number, but for the bad inode ?

There is a plan for how to handle online resizing for > 2^32 block
filesystems, but it hasn't been implemented yet.  The basic support
for it is there; that's what the META_BG feature is designed to
support, so existing kernels will be able to deal with resized large
filesystemes.  But the code to actually do the on-line resizing hasn't
been implemented yet.

For the bad block inode, the solution is to make it be extent mapped
inode.  This also hasn't been implemented yet, but this is a much
simpler one to write.  The main reason why we haven't is that modern
disks rarely have system-visible bad blocks; normally the hard drive
has its own bad block remapping layer in hardware so we never see a
bad block until the disk is failing so badly it needs to be replaced
ASAP.

						- 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