Re: [RFC] FSFS filesystem options (long, sorry)

"Michael Sinz" <Michael.Sinz@sinz.org> writes:

>> It's not a matter of storage space but performance. Shorter names means
>> that more of them fit into a directory block on disk, more of them fit
>> into
>> cache, and more of them are returned with each getdents() system call.

>That would be true for which filesystems? (That is, with names this short)
>Many of them optimize space usage granular chunks to keep things on
>32-bit and/or 64-bit boundaries at a minimum - if not full cache-line sizes=
>.

Most FFS-derived (including ext2/3) file systems pack entries inside
directory blocks, because the maximum file name size is much bigger
than the typical name. This should be true for most B-tree based file
systems as well.

Note that keeping stuff on 32- or 64-bit boundaries does not alter the
equation much; it just means that a one byte shorter name sometimes saves
zero bytes, sometimes 4 or 8 bytes.

(I was wrong about getdents() as it returns the entries into fixed-length
records.)

>(Strangely aligned data structures are much slower than a slight loss in
>data density - especially at the byte and word level due to the need to
>execute mixed or multiple bus cycles to collect the various parts.)

That statement is not generally true. For both x86 and PowerPC, the
penalty for unaligned accesses is generally small, and for any
architecture definitely worth it if it can decrease the number disk
accesses. Remember that we are not talking about data structure layout
in memory here.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Mar 5 17:23:31 2007