Date: Mon, 20 May 2013 14:22:49 -0400 From: John Baldwin <jhb@freebsd.org> To: freebsd-current@freebsd.org Cc: Hartmut Brandt <hartmut.brandt@dlr.de>, Rick Macklem <rmacklem@uoguelph.ca>, kib@freebsd.org, current@freebsd.org Subject: Re: files disappearing from ls on NFS Message-ID: <201305201422.49555.jhb@freebsd.org> In-Reply-To: <alpine.BSF.2.00.1305151032540.35662@KNOP-BEAGLE.kn.op.dlr.de> References: <1392815611.361000.1368569353890.JavaMail.root@erie.cs.uoguelph.ca> <alpine.BSF.2.00.1305151032540.35662@KNOP-BEAGLE.kn.op.dlr.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wednesday, May 15, 2013 4:38:38 am Hartmut Brandt wrote:
> On Wed, 15 May 2013, Rick Macklem wrote:
>
> RM>Well, getdents() basically just calls kern_getdirentries() and it calls
> RM>VOP_READDIR() { which is called nfs_readdir() in the NFS clients }.
> RM>nfs_readdir() calls ncl_bioread() to do the real work of finding the
> RM>buffer cache blocks and copying the data out of them.
> RM>One thing you might check via printf()s is whether the buffer cache
> RM>has the zero'd data in it before it copies it to userland.
>
> I now dump the data just before the call to vn_io_fault_iomove in
> ncl_bioread(). So what I do:
>
> 1. reboot
> 2. login
> 3. ls
> -> I see that it is moving 4 blocks 4k each to the user and they look
> fine
> 4. wait half an hour
> 5. ls
> -> now there is only one block, which contains zeros starting from
> 0x200.
>
> Note that I don't do anything else on that machine during that time.
To be clear, you are still seeing zero'd data in your printfs? Also, it seems
like it is passing the wrong size now? Can you output the various size fields
(b_resid, n, n_direofoffset, uio_offset, and uio_resid)?
--
John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201305201422.49555.jhb>