In article <20011021093547.A24227@work.bitmover.com>,Larry McVoy <lm@bitmover.com> wrote:>>One of the engineers here has also seen this. The root cause is that>readdir() is returning a file multiple times. We've seen it on tmpfs.

Yes. "tmpfs" will consider the position in the dentry lists to be the"offset" in the file, and if you remove files from the directory as youdo a readdir(), you can get the same file twice (or you can fail to seefiles).

If somebody has a good suggestion for what could be used as a reasonablyefficient "cookie" for virtual filesystems like tmpfs, speak up. In themeantime, one way to _mostly_ avoid this should be to give a big bufferto readdir(), so that you end up getting all entries in one go (whichwill be protected by the semaphore inside the kernel), rather thanhaving to do multiple readdir() calls.

(But we don't have an EOF cookie either, so..)

The logic, in case people care is just "dcache_readdir()" infs/readdir.c, and that logic is used for all virtual filesystems, sofixing that will fix not just tmpfs..

Now, that said it might be worthwhile to be more robust on anapplication layer by simply just sorting the directory. As you pointout, NFS to some servers can have the same issues, for very similarreasons - on many filesystems a directory "position" is not a stablething if you remove or add files at the same time.

So I would consider the current tmpfs behaviour a beauty wart andsomething to be fixed, but at the same time I also think you'redepending on behaviour that is not in any way guaranteed, and I wouldargue that the tmpfs behaviour (while bad) is not actually strictly abug but more a quality-of-implementation issue.