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]

Message-id: <48DC1806.90805@sun.com>
Date:	Fri, 26 Sep 2008 03:00:22 +0400
From:	Alex Tomas <bzzz@....com>
To:	Andreas Dilger <adilger@....com>
Cc:	ext4 development <linux-ext4@...r.kernel.org>
Subject: Re: [RFC] dynamic inodes

Andreas Dilger wrote:
> Alternately, any inode >= 2^32 would be dynamic?  One clear benefit of
> putting the dynamic inodes at the end of the number space is that they
> will only be used if the static inodes are full, which reduces risk due
> to corruption and overhead due to dynamic allocations.

the highest (63th) bit put dynamic inodes at the end, no? the idea is that
using 48 bits we can address block directly, w/o any additional lookup via
some metainode. essentially this is just a way to introduce 64bit addressable
fragments of 2^(64-48-1) size.

>>   * each block is covered by two bits: in inode (I) and block (B) bitmaps:
>>     I: 0, B: 0 - block is just free
>>     I: 0, B: 1 - block is used, but not contains inodes
>>     I: 1, B: 0 - block is full of inodes
>>     I: 1, B: 1 - block contains few inodes, has free space
> 
> Storing B:0 for an in-use block seems very dangerous to me.  This also
> doesn't really address the need to be able to quickly locate free inodes,
> because it means "I:1" _might_ mean the inode is free or it might not,
> so EVERY "in-use" inode would need to be checked to see if it is free.

just combine I and B into single bitmap:
1) when you look for free block it's any 0 bit in bitmap made by (I & B)
2) when you look for free inode (in current inode blocks) it's any 1 bit
    in bitmap made again by (I & B), then you read corresponded block and
    find free slot there (for example, it can be null i_mode)

looks very simple and doable?

> We need to start with a "dynamic inode bitmap" (DIB) that is mapped from
> an "inode table file" (possibly only for the dynamic inode table blocks).
> Free inodes can be scanned using the normal ext4_find_next_zero_bit()
> in each of the bitmaps.

the idea is that we can implement truly dynamic and varlen inodes w/o
introducing special files, using existing structures.

thanks, Alex

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