On Thu, Feb 14, 2013 at 05:10:02PM +1100, Dave Chinner wrote: > On Wed, Feb 13, 2013 at 05:20:52PM -0500, Theodore Ts'o wrote: > > Telldir() and seekdir() are basically implementation horrors for any > > file system that is using anything other than a simple array of > > directory entries ala the V7 Unix file system or the BSD FFS. For any > > file system which is using a more advanced data structure, like > > b-trees hash trees, etc, there **can't** possibly be a "offset" into a > > readdir stream. > > I'll just point you to this: > > http://marc.info/?l=linux-ext4&m=136081996316453&w=2 > > so you can see that XFS implements what you say can't possibly be > done. ;) > > FWIW, that post only talked about the data segment. I didn't mention > that XFS has 2 other segments in the directory file (both beyond > EOF) for the directory data indexes. One contains the name-hash btree > index used for name based lookups and the other contains a freespace > index for tracking free space in the data segment. OK, so in some sense that reduces the problem to that of implementing readdir cookies for directories that are stored in a simple linear array. Which I should know how to do but I don't: I guess all you need is a provision for making holes on remove (so that you aren't required move existing entries, messing up offsets for concurrent readers)? Purely out of curiosity: is there a more detailed writeup of XFS's directory format? (Or a pointer to a piece of the code a person could understand without losing a month to it?) --b. > > IOWs persistent, deterministic, low cost telldir/seekdir behaviour > was a problem solved in the 1990s. :) -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
