Re: Agressive selective pre-allocation

["Ragnar Kjørstad" <reiserfs@ragnark.vestdata.no>]

On Thu, Dec 12, 2002 at 05:46:08PM +0300, Hans Reiser wrote:
> >Yes, maildir is not always faster.
> >
> >First problem is disk-layout. The way it works with reiserfs3.6 and
> >default hashes the inodes and files are written in different orders and
> >the disk does a lot of unneeded seeks. 
> >
> You mean the names are written in an order different from the stat data 
> and file bodies, and the stat data and file bodies have the same order.
> 
> This is because we sort filenames by filename, and  sort stat data and 
> file bodies by objectid which tends to be ordered by creation time.

Exactly.

> We should implement a plugin that sorts filenames by creation time, and 
> that will cause our performance to resemble ext2 more (meaning that for 
> large directories the performance will fall apart, but for small 
> directories there might be some advantage from not sorting by name). 

Yes, or you could do as I did in my maildir-specific hash - make a hash
that tends to resemble creation-order. For maildir this can be done
pretty easily as filenames can be predicted and actually contain
information about creation-order.

> I 
> think that sorting file bodies by filename would require a larger key, 
> so I hesitate at that, but maybe it would be interesting to explore also.

That would be _really_ interesting, but I don't understand exactly what
would be needed. 

Am I right to assume that there are actually several seperate entities
that are related to the allocation/ordering:
- the reiserfs-key idenitfying the inode
- tree-nodes that hold the allocation-information about the file
  (I guess extent-lists in reiserfs4)
- the blocks actually allocated for the data.

So both the choice of the inode-key and the allocation-policy for new
tree-nodes and data-blocks could affect file-ordering? Since the key is
generated from the hash that should already be in directory-entry-order,
but what about the other two?

Frankly last time I checked I found the way that directories and
allocation work not too well documented. Perhaps I just didn't look the
right places... Or maybe I must just be prepared to take the time to
read the source properly to understand this.


> >It is also important that readdir-order matches the ondisk layout, but
> >that is perhaps already the case?
> >
> If you copy a directory, then after the copy the readdir order matches 
> the ondisk layout.

Yes, that's what I do now when my maildirs get too slow. It makes a
huge difference.


-- 
Ragnar Kjørstad