RFC ocfs2: Directory indexing support
Get series with b4
b4 am [email protected]Versions newest first
- v1 RFC Latest4 patches 0 repliesNew
Patches in v1 No applies recorded yet
| # | Subject and files | Size | Replies | Applied |
|---|---|---|---|---|
| 1/4 | ocfs2: turn __ocfs2_remove_inode_range() into ocfs2_remove_btree_range() | +0 | 0 replies | |
| 2/4 | ocfs2: Introduce dir lookup helper struct | +0 | 0 replies | |
| 3/4 | ocfs2: Add a name indexed b-tree to directory inodes | +0 | 0 replies | |
| 4/4 | ocfs2: Introduce dir free space list | +0 | 0 replies |
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.
Cover letter [Ocfs2-devel] [RFC][PATCH 0/4] ocfs2: Directory indexing support
Quoted 2 lines · Mark Fasheh
The following patches implement indexed directory support in Ocfs2, mostly according to the design doc I wrote up a while ago:
<snip>
Quoted 4 lines
Very basic ocfs2-tools patches will also follow in the next couple days or so. This will mostly be mkfs and debugfs support. I think it might be best to build the libocfs2 support on top of whatever patches we have for extended attributes as the tree code will have to change for that.
I agree. I hope we see those soon. We have a lot of stuff now
that isn't fully tools supported.
Quoted 9 lines
Open questions:
Should we just drop the signature in
ocfs2_dir_block_trailer? I can't help but feel that it might have limited usefulness as it's not at the front of the block (like the rest of our signatures) and that the nature of a dirent block might be that we can't trust the existence of the signature to actually mean there's a validocfs2_dir_block_trailerthere. The answer is probably still to keep the signature, but I thought I'd throw this out there.
I like having it, because it sticks right out in bvi/hexdump.
With any of our metadata structures, we generally have to figure out if they are "really" a such-and-such by hand after validating the signature. But if we start from the knowledge "block N is or is not supposed to be of type X", the signature is a quick way to see if something is wrong.
Quoted 5 lines
Is it worth storing index (
ocfs2_dx_entry) records inline inside ofocfs2_dx_root_blockand only growing out to a tree when we exhaust the available space? Running the math, we could store between 18 (512 byte blocks) and 242 (4k blocksize) records in the space occupied by the extent list.
I'd say we should do _something_. Many (most?) directories have
less than 242 entries, and this saves us a sync read on any cold-cache lookup. What about a way we could readahead the first index leaf instead? I suppose we could store "first leaf" on the inode right next to the dx root, and then fire of readahead for the first leaf right before we sync-read the dx_root. If the directory fits in one index leaf, that first leaf is already in our cache. If not, we just ignore it. For 4k/4k, this is a single block. Then the dx_root doesn't have to have special logic for inline-entries.
Quoted 6 lines
In order to keep the code simple, I've gone with a single linked-list for the free dirent block search. There might be situations though, where this performs poorly. My plan is to version the free dirent block list so that we can 'upgrade' it (maybe to multiple lists) at a later point. Old versions would fall back to the less optimized unindexed leaf search. That way the upgrade would be seamless to the user.
I always liked this. Wouldn't this mean that old versions might
leave 'full' dirblocks on the free list?
Joel
Signature · 9 lines
"There are some experiences in life which should not be demanded
twice from any man, and one of them is listening to the Brahms Requiem."
- George Bernard Shaw
Joel Becker
Principal Software Developer
Oracle
E-mail: joel.becker at oracle.com
Phone: (650) 506-8127