Re: DCACHE Pinning Problems with rm -r on 2.2.15/2.3.99Pre3 withNWFS2.2.2

From: Stephen C. Tweedie (sct@redhat.com)
Date: Tue Apr 04 2000 - 12:01:27 EST


Hi,

On Tue, Apr 04, 2000 at 03:56:54PM +0200, Jamie Lokier wrote:
>
> Which is unfortunate because the computed LSEEK_CUR appears in Glibc's
> readdir(). It's a corner case. To remove the LSEEK_CUR, unfortunately
> you have to use another syscall in the normal case.

What is the problem? You just cannot assume that the pointer
progresses in a nice, arithmetic patter in directories. If you are
at lseek() point P and read Q bytes, you are not going to end up
at P+Q: the actual file location you end up at depends on how much
padding there was in the directory and how much extra filesystem
metadata was there that didn't get returned to user space. It's
not just odd cases like NFS that have this property: even ext2
does.

lseek() on directories is hardly performance-critical in any case,
so it's much more important to get it right than to get it fast.

--Stephen

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Fri Apr 07 2000 - 21:00:12 EST