G'Day Folks, I'm testing out the prototype NFSv3 DTrace provider, which is working well so far (and for anyone who missed the news, the NFSv4 provider was putback to Solaris Nevada last year and works great).
One of my scripts, nfsv3snoop.d, prints filename, offset and size. While reading through a file remotely (using cksum), it traced the following: # ./nfsv3iosnoop2.d TIME(us) CLIENT OP OFFSET BYTES PATHNAME 738601899 192.168.17.75 Rs 0 4096 /export/stuff/words 738613529 192.168.17.75 Rd 0 4096 /export/stuff/words 738614258 192.168.17.75 Rs 4 28672 /export/stuff/words 738627681 192.168.17.75 Rd 4 28672 /export/stuff/words 738628599 192.168.17.75 Rs 32 32768 /export/stuff/words 738628683 192.168.17.75 Rd 32 32768 /export/stuff/words 738629509 192.168.17.75 Rs 96 32768 /export/stuff/words 738629597 192.168.17.75 Rd 96 32768 /export/stuff/words 738629800 192.168.17.75 Rs 128 32768 /export/stuff/words 738629886 192.168.17.75 Rd 128 32768 /export/stuff/words 738630316 192.168.17.75 Rs 160 32768 /export/stuff/words 738630439 192.168.17.75 Rd 160 32768 /export/stuff/words 738630748 192.168.17.75 Rs 64 32768 /export/stuff/words 738630945 192.168.17.75 Rd 64 32768 /export/stuff/words 738632525 192.168.17.75 Rs 192 12288 /export/stuff/words 738632577 192.168.17.75 Rd 192 10055 /export/stuff/words ^C Rs == Read start, Rd == Read done. OFFSET is in Kbytes, BYTES is in bytes. Note how the read requests skip the 64 Kbyte offset, and then return to it 1.2 ms later? Is there a reason why NFSv3 would do this? ... I can use DTrace to investigate - someone might already know what's up. This is on a single CPU server, and is repeatable. Brendan This message posted from opensolaris.org
