On Fri, Sep 21, 2007 at 11:02:58AM +0200, Andi Kleen wrote: > I assume you mean sort by inode, because sort by htree key would > be as bad as htrees. > > But wouldn't that break parallel readdir for a directory that just grows > from <32/64K to over it? e.g. if the sort moves already read > entries to after the cursor readdir would return some entries twice. No, it wouldn't break it because after snapshotting the tree, we would only use the snapshot and not refer to the on-disk format until the directory file handle is closed or there is an explicit lseek to 0. To quote from the spec: If a file is removed from or added to the directory after the most recent call to the opendir() or rewinddir() function, whether a subsequent call to the readdir() function returns an entry for that file is unspecified. So, if some program does the stupid thing and opens a directory, doesn't use it for five hours, and in the meantime 2,000 files are created, it's OK if we only return the set of files that were in existence when the opendir() was originally called. This makes us OK in terms of spec conformance, and given that real life programs don't do stuff this stupid, we should be fine. - Ted - To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
