linux-ext4 - Re: [RFC] dynamic inodes

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]

Date:	Fri, 26 Sep 2008 04:36:07 -0600
From:	Andreas Dilger <adilger@....com>
To:	"Jose R. Santos" <jrs@...ibm.com>
Cc:	Alex Tomas <bzzz@....com>,
	ext4 development <linux-ext4@...r.kernel.org>
Subject: Re: [RFC] dynamic inodes

On Sep 25, 2008  20:10 -0500, Jose R. Santos wrote:
> One way to get around this is to implement the exact opposite of what I
> proposed earlier and have a block group with no inode tables.  If we do
> a 1:1 distribution of inode per block and don't allocate inodes tables
> for a series of block groups within a flexbg we could later on attempt
> to allocate new inode tables when we run out of inodes.  If we leave
> holes in the inode numbers for the missing inode tables, adding new
> inode tables in these block groups would not require any inode
> renumbering.  This also does not break the current inode allocator
> which would be a good thing.  This should be even simpler to implement
> than the previous proposal.  The drawbacks are that when allocating a
> new inode table, the 1:1 distribution of inode per block would mean
> that we need to find a bigger chunk on contiguous blocks to since we
> have bigger inode tables per block group.  Since the current inode
> allocator tries to keep a 10% of blocks in a flexbg free, finding
> contiguous blocks may not be a really big issue.  Another issue is 64bit
> filesystem if we use a 1:1 scheme.
> 
> This would be like uninitialized inode tables with the added steps of
> finding free blocks, allocating a new inode and zeroing the newly
> created inode table.  Since we could chose to allocate a new inode
> table on a flexbg with the most free blocks, this could keep filesystem
> meta-data/data layout consistently close together to maintain
> predictable performance.  This option also has no overhead compared to
> the previous proposal.

The problem with leaving gaps in the itable is that this needs the
filesystem to be created in this manner in the first place, while adding
them at the end can be done to any filesystem.  If we are preparing the
filesystem in advance for this we could just reserve enough GDT space
too (as online resize already does to some extent)..

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html