On Wed, 2007-12-05 at 20:07 +0530, Bharata B Rao wrote: > In this approach, the cached dirents are given offsets in the form of > linearly increasing indices/cookies (like 0, 1, 2,...). This helps us to > uniformly define offsets across all the directories of the union > irrespective of the type of filesystem involved. Also this is needed to > define a seek behaviour on the union mounted directory. This cache is stored > as part of the struct file of the topmost directory of the union and will > remain as long as the directory is kept open. That's a little brute force, don't you think? Especially the memory exhaustion seems to really make this an undesirable approach. I think the key here is what kind of consistency we're trying to provide. If a directory is being changed underneath a reader, what kinds of guarantees do they get about the contents of their directory read? When do those guarantees start? Are there any at open() time? Rather than give each _dirent_ an offset, could we give each sub-mount an offset? Let's say we have three members comprising a union mount directory. The first has 100 dirents, the second 200, and the third 10,000. When the first readdir is done, we populate the table like this: mount_offset[0] = 0; mount_offset[1] = 100; mount_offset[2] = 300; If someone seeks back to 150, then we subtrack the mount[1]'s offset (100), and realize that we want the 50th dirent from mount[1]. I don't know whether we're bound to this: http://www.opengroup.org/onlinepubs/007908775/xsh/readdir.html "If a file is removed from or added to the directory after the most recent call to opendir() or rewinddir(), whether a subsequent call to readdir() returns an entry for that file is unspecified." But that would seem to tell me that once you populate a table such as the one I've described and create it at open(dir) time, you don't actually ever need to update it. The storage for this is only comparable to the number of mounts that you have. One issue comes if we manage to overflow our data types with too many entries in too many submounts. But, I guess we can just truncate the directory in that case. -- Dave - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
