[Tux3] Q: inode numbering, and placement on-disk

[Daniel Phillips]

On Wednesday 25 February 2009, Philipp Marek wrote:
> Hello everybody,
> 
> I'm not sure about a small point in the Tux3 design; please excuse me if 
> that's written somewhere I just didn't look.
> 
> There are some hacks to sort the directory contents by inode number before 
> doing the stat() calls on the names; it's been proposed in kernel, done via 
> LD_PRELOAD, and explicitly coded in some applications.
> 
>   [ I'm interested in that because my pet project (fsvs.tigris.org) uses
>     a per-inode-number globally-sorted list of entries of whole directory
>     hierarchies, which makes querying them faster than "find" on cold
>     caches. ]
> 
> Now, if I understand Tux3 design correctly, it's no longer the case that the 
> inode numbers have any meaning regarding the on-disk location (because of 
> snapshots, versioning, and other strategies), so this hack (or "feature", if 
> you like) wouldn't work anymore, would it?

Hi Phil,

Tux3 does in fact attach significance to inode numbers.  Currently, the
file data allocation goal (a block number) is used as the inode number
goal, and Tux3 will assign the next available inode number after that
to a new file.  In time we will improve this strategy to work well when
you come back and create a new file in a directory later, most probably
by maintaining or computing a overall directory allocation goal based
on physical location of files already in the directory.

As it is now, when you initially write a directory, inode numbers will
correspond spatially quite well to file data block ordering, but this
pristine condition will degenerate over time, which can be regarded as
an optimization bug that needs to be fixed.

Regards,

Daniel


_______________________________________________
Tux3 mailing list
Tux3 at tux3.org
http://mailman.tux3.org/cgi-bin/mailman/listinfo/tux3