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 10:33:09 -0400
From:	Theodore Tso <tytso@....edu>
To:	Andreas Dilger <adilger@....com>
Cc:	Alex Tomas <bzzz@....com>,
	ext4 development <linux-ext4@...r.kernel.org>
Subject: Re: [RFC] dynamic inodes

On Fri, Sep 26, 2008 at 04:33:22AM -0600, Andreas Dilger wrote:
> > This is actually the big problem; with META_BG, in order to find the
> > group descriptor blocks, it assumes that the first group descriptor
> > can be found at the beginning of the group descriptor block, which
> > means it has to be found at a certain offset from the beginning of the
> > filesystem.  And this would not be true for inode-only block groups.
> 
> We could special-case the placement of the GDT blocks in this case, and
> then put them into the proper META_BG location when/if the blocks are
> actually added to the filesystem.

Yes, but where do you put the GDT blocks in the case of where there is
no more space in the reserved gdt blocks?  Using some inode is
probably the best bet, since we would then know where to find the GDT
blocks.

My suggestion of using inode numbers growing downward from the top of
the 2**32 number space was to avoid needing to move the GDT blocks
into their proper place if and when the filesystem is grown; it
simplifies the code needed for the on-line resizing, and it also means
that when you do the on-line resizing the filesystem gets more inodes
along with more blocks.  If we move the GDT blocks into their proper
place, then the filesystem gets more blocks, but not more inodes; but
if the inodes are dynamically grown automatically by the filesystem,
maybe that's not a problem.

> Alternately, we could put the GDT into the inode and replicate the whole
> inode several times (the data would already be present in the filesystem).
> We just need to select inodes from disparate parts of the filesystem to
> avoid corruption (I'd suggest one inode from each backup superblock
> group), point them at the existing GDT blocks, then allow the new GDT
> blocks to be added to each one.  The backup GDT-inode copies only need
> to be changed when new groups are added/removed.

Yes, that's probably the best solution, IMHO.

					- 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