On Thu, Mar 13, Ulrich Drepper wrote: > There is very little overhead. Since we copy using getdents multiple > records it is more efficient than implementing readdir in the kernel. > This is how efficient normal directory operations must remain. The only > slight inefficiency is that we have to copy the entries after getdents() > because the d_type field is not in the place we expect it at userlevel. > For this a new interface could help. BTW, Since some filesystem always give DT_UNKNOWN an additional stat is necessary to implement whiteout filtering. I don't want to do that in kernel-space if possible ... > Regarding questions you have: if a directory currently is read and file > are added or removed, all bets are off. > > re seeking: you have to support seeking. There is no way around it. > Once again, if any file has been added/removed, all bets are off. So, > why not provide a cookie similar to what is done today? I think it is > not acceptable to require caching the entire directory content at > userlevel. It's bad enough if we have to store the file names for > duplicate elimination. Which basically means tracking of the "space" between dirents and maintaining the relative order of entries. Which is a pain. I already tried to solve this problem for tmpfs before and it needs a hugh amount of kernel memory for open directories. In the end I only know of one situation where it is used: very old glibc when running 32bit applications on 64bit kernel. Cheers, Jan -- 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
