[lkml]   [2001]   [Oct]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Kernel Compile in tmpfs crumples in 2.4.12 w/epoll patch
On October 21, 2001 07:50 pm, Linus Torvalds wrote:
> In article <>,
> Larry McVoy <> 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 you
> do a readdir(), you can get the same file twice (or you can fail to see
> files).
> If somebody has a good suggestion for what could be used as a reasonably
> efficient "cookie" for virtual filesystems like tmpfs, speak up. In the
> meantime, one way to _mostly_ avoid this should be to give a big buffer
> to readdir(), so that you end up getting all entries in one go (which
> will be protected by the semaphore inside the kernel), rather than
> having to do multiple readdir() calls.

Assuming the "cookie" is an ordinal position in some predictable traversal of
a directory, e.g., storage order, then the problem can be resolved with some
cooperation from create and delete. For a create, the cookie should be
incremented if the position of the create is before the cookie. Likewise,
for a delete, the cookie should be decremented if the delete is before the

> (But we don't have an EOF cookie either, so..)
> The logic, in case people care is just "dcache_readdir()" in
> fs/readdir.c, and that logic is used for all virtual filesystems, so
> fixing that will fix not just tmpfs..
> Now, that said it might be worthwhile to be more robust on an
> application layer by simply just sorting the directory. As you point
> out, NFS to some servers can have the same issues, for very similar
> reasons - on many filesystems a directory "position" is not a stable
> thing if you remove or add files at the same time.
> So I would consider the current tmpfs behaviour a beauty wart and
> something to be fixed, but at the same time I also think you're
> depending on behaviour that is not in any way guaranteed, and I would
> argue that the tmpfs behaviour (while bad) is not actually strictly a
> bug but more a quality-of-implementation issue.
> Linus

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:08    [W:0.079 / U:5.840 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site