Hi,
On Wed, Nov 27, 2002 at 08:55:54PM +0000, Stephen C. Tweedie wrote:
> Having said that, the server is clearly in error in sending a
> duplicate cookie in the first place, and if it did so we'd never get
> into such a state.
And it's ext3's fault. Reproducer below. Run the attached readdir
against an htree directory and you get something like:
[root@host1 htest]# ~sct/test/fs/readdir
getdents at f_pos 0000000000000000 returned 4084.
getdents at f_pos 0X0000000B753BE7 returned 4080.
getdents at f_pos 0X000000158C4C61 returned 4080.
getdents at f_pos 0X00000021E86BDC returned 4080.
getdents at f_pos 0X0000002D60F25D returned 4080.
getdents at f_pos 0X00000037BC95D7 returned 4096.
getdents at f_pos 0X000000434E2AA3 returned 4080.
getdents at f_pos 0X0000004EF11AE6 returned 4080.
getdents at f_pos 0X000000596EBC2F returned 4080.
getdents at f_pos 0X00000065A76668 returned 4080.
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.
--Stephen
This archive was generated by hypermail 2b29 : Sat Nov 30 2002 - 22:00:20 EST