| |||||||||||||
Widening ext4's readdir() cookieWidening ext4's readdir() cookiePosted Mar 28, 2013 14:14 UTC (Thu) by etienne (subscriber, #25256)In reply to: Widening ext4's readdir() cookie by paulj Parent article: Widening ext4's readdir() cookie
> In which case, why not just keep a separate, simpler index?
There is an obvious index, which is the index of the inode in the directory as written to the hard disk sectors - but all index are worse than cookies because if you are currently using file 4 (out of 10), and someone removes the file number 2, when you will ask for file 5, you will skip a file...
(Log in to post comments)
Widening ext4's readdir() cookie Posted Mar 28, 2013 14:27 UTC (Thu) by paulj (subscriber, #341) [Link]
Because you've changed the ID of file 5, because you made its ID dependent on an ephemeral order.
If you make the IDs stable, so they never change so long as the entry exists, then the problem is gone. The IDs are stable, and so the ordering between them is stable. You can do this through an additional index (in the data-structure sense).
The "pain" seems to be that the ext3+ devs are trying to achieve this stable order by hacking around in the details an existing index of an ID that does NOT have an absolute order (the hashes of names). That wouldn't be necessary at all if they'd just add an additional stable, absolutely ordered, finite ID with its own index. The namespace-hash and the finite-ID could each have their own, simple index - no nasty hacks needed.
(It seems to me, but I could be dreadfully wrong, or perhaps there are some critical details missing from the reporting ;) ).
|
|||||||||||||