2016-05-31 19:44 GMT+02:00 Al Viro <viro@xxxxxxxxxxxxxxxxxx>: > On Tue, May 31, 2016 at 06:25:24PM +0200, Stef Bon wrote: > >> I've been thinking about the non serialized readdirs. I do not understand. >> Readdirs have to be serialized, since the offset of the next readdir >> (belonging to the opendir) is known when the current readdir is >> finished: >> "start where current left". > > They are serialized per struct file (and so'd lseek() on them, for that > matter). So the state that is associated with an opened file is just > fine; it's modifiable state associated with directory itself, and shared > between all opened file that would be a problem. I'm really sorry but what do mean with struct file? We're talking about directories and I do not understand what the meaning is of the struct file here. > > IOW, they can do readdir in parallel exactly in the cases when lseek > done by one of them would not affect another. And when lseek does not affect another? Is this right: When there are no changes in the entries, no entries are created or removed (or moved away)?? (which probably means the cache of names in the directory is uptodate). Stef -- 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
