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  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:	Wed, 14 Mar 2012 10:17:37 -0400
From:	Zach Brown <>
To:	Ted Ts'o <>, Yongqiang Yang <>,
	Phillip Susi <>,
	Andreas Dilger <>,
	Lukas Czerner <>,
	Jacek Luczak <>,
	"" <>,
	linux-fsdevel <>,
	LKML <>,
	"" <>
Subject: Re: getdents - ext4 vs btrfs performance

> We could do this if we have two b-trees, one indexed by filename and
> one indexed by inode number, which is what JFS (and I believe btrfs)
> does.

Typically the inode number of the destination inode isn't used to index
entries for a readdir tree because of (wait for it) hard links.  You end
up right back where you started with multiple entries per key.

A painful solution is to have the key in the readdir tree allocated by
the tree itself -- count key populations in subtrees per child pointer
and use that to find free keys.  You still have the problem of
correlating entry keys and the location of inodes, but at least now you
have a structure to navigate to try and do that.  You can also trivially
re-use freed keys and have densely packed readdir keys that won't break
32bit f_pos so quickly.

btrfs just punts and has an incrementing 64bit counter per directory
that determines a new entry's position in readdir.  Accompanied by the
obligatory "will be smarter some day" comment :).

- z
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to
More majordomo info at

Powered by blists - more mailing lists