Messages in this thread | | | Date | Thu, 28 Nov 2002 17:13:24 +0000 | From | "Stephen C. Tweedie" <> | Subject | Re: [Ext2-devel] Re: [NFS] htree+NFS (NFS client bug?) |
| |
Hi,
On Thu, Nov 28, 2002 at 04:44:39PM +0000, Stephen C. Tweedie wrote: > And it's ext3's fault. Reproducer below. Run the attached readdir > against an htree directory and you get something like: > ... > getdents at f_pos 0X0000007060CF8B returned 4080. > getdents at f_pos 0X0000007B9213FA returned 1464. > getdents at f_pos 0X0000007B9213FA returned 0. > Final f_pos is 0X0000007B9213FA. > [root@host1 htest]# > > The problem is that the htree readdir code is not updating f_pos after > returning the very last chunk of data to the caller. That doesn't > hurt most callers because the location is cached in the filp->private > data, but it really upsets NFS.
In fact, it's not clear what we _can_ return as f_pos after the last dirent.
We're only using 31-bit hashes right now. Trond, how will other NFS clients react if we return an NFS cookie 32-bits wide? We could easily use something like 0x80000000 as an f_pos to represent EOF in the Linux side of things, but will that cookie work if passed over the wire on NFSv2?
The alternative is to hack in a special case so that (for example) we consider a major htree hash of 0x7fffffff to map to an f_pos of 0x7ffffffe and just consider that a possible collision, so that 0x7fffffff is a unique EOF for the htree tree walker.
--Stephen - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |