boo! even with limited IO, i can't see why the database rebuild won't be hastened with the filesystem's b-tree design (4 lvl depth). iirc, most of the time is serching for a certain fid, then reading it and writing to the database. the whole point of fidsifting was so that the whole search process wouldn't take as long, by partitioning the big directory of fids into smaller chunks. so, even though the empeg's IO is limited by its bus, shaving off time on how long it takes to search for a fid so that it gets into memory faster will probably help. its ok tho if it doesnt. i've always wanted to just mess with the kernel source code. might as well start with this. =)

on a tangent, reiserfs4 seems exciting, and its an interesting read on the whole philosophy on its design. and the preliminary benchmarking is blowing away all the current filesystems (reiserfs3, xfs, jfs).