linux-ext4 - Re: [PATCH V5 00/23] ext4: Add inline data support.

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: <67344EBF-9B68-46AD-8936-4C383D0A2072@whamcloud.com>
Date:	Mon, 13 Aug 2012 20:43:49 -0600
From:	Andreas Dilger <adilger@...mcloud.com>
To:	Theodore Ts'o <tytso@....edu>
Cc:	Tao Ma <tm@....ma>,
	"linux-ext4@...r.kernel.org" <linux-ext4@...r.kernel.org>
Subject: Re: [PATCH V5 00/23] ext4: Add inline data support.

On 2012-08-13, at 9:04, Theodore Ts'o <tytso@....edu> wrote:
> I had an idea which I think would make inline directories more
> efficient, although it wouldn't be a backwards compatible change with
> the existing patch sets to date.
> 
> We don't actually need to store the entry for '.', since we know what
> that should be, and we could just store the parent directory in a
> 4-byte entry.

> By not storing the full directory entries for "." and
> "..", we would save 20 bytes, which for a 256 byte inode where only
> 120 bytes or so are available for the inline directory, is pretty
> significant.  (We can just synthesize them for the benefit of readdir
> and lookup --- and I'm pretty sure the VFS is doing its own synthesis
> for "." and possibly ".." already as far as lookup is concerned.)

One concern is that we have expanded the dentries for "." and ".." to store the Lustre FID in the expanded dirent. The "." dirent isn't needed for in-inode directories, and I suppose we could get the Lustre ".." FID from the "link" xattr (parent inode+name) already stored in the inode as well...  Both are useful for robustness with external directory files, but  they aren't useful inside the inode. 

Other than that, it seems reasonable to economize on space inside the inode. It makes the handling a bit more complex.

Cheers, Andreas--
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