Hello all,

Recently, my lazy ass went from 4.6-current snap to the most recent
4.8-current snap (#647: Fri Nov 26, amd64). Machine in question is
mostly a local file server, NFS to a few Macs. I say mostly, 'cause it
does some other stuff, and sits in a DMZ.

Since the upgrade to 4.8, I'm unable to read /some/ files from the nfs
server to the macs. I say some, because in testing I've been able to
ascertain the following:

1. I can write any size file from the mac to the nfs server. No issue.
2. I can write a small file (like 5 KiB), and read it back to the Mac.
3. I can write a large file (like 700 MiB), and cannot read it back to
the Mac.
4. I am unable to read any previously existing files on the NFS share to
the Mac, whether they be large, or small.

Because the machine is in a DMZ, I made sure to disable the
DMZ->Internal filtering rules and stuff to rule out any stupidity.
Traffic dumps show no blocked packets.

While grasping at straws, I set vfs.nfs.iothreads=4. The
Mac is mounting the share as -o resvport,hard,intr,nolock.

The troubleshooting results thus far are just erratic enough to have me
believe it's nothing I've done; nothing is making sense. I'm basically
looking for corroboration here. Can anyone else replicate this?
-- 
Jason 

[ message continues ]

I am experiencing something similar on 4.8-current (server) and MacOSX
10.5.8 (client). I suspect the MacOSX to be the quilty one, as no other
NFS client shows any of these symptoms.

From the mac, I can write a file to the (auto)mounted share (/media)
and read it back, but I cannot read any of the files that existed there
before I mounted. A simple 'cat /media/.../file.txt' results in nothing
(the command is still running); after a while, a window pops up saying
'Server connection interrupted: media [Disconnect]'. I can _list_ the
content of the mounted share though.

I am (auto)mounting it with -resvport,noauto,nodev,noexec,noatime.
No filtering is done in between the boxes; they are on the same LAN,
pf is not running. I need to look at what exactly the mac firewall is
doing I guess.

	Jan

[ message continues ]

There's dtrace on Mac.


[ message continues ]

Thanks Jan, that sounds a lot like what I'm seeing on several 10.6.5 OSX
clients. To be sure, it's the Mac clients with the issue; I've been able
to mount the share on another OpenBSD machine on the network and it
functions normally.

Whatever the issue, it was unexposed using any previous snapshots, and in
my case, there is no OSX firewall involved. I'm gonna start dumping
traffic at the OSX clients and see if I can find something there.

In the meantime, anyone have any recall of recent-ish changes to the NFS
code? I'm gonna start combing through src-changes now...

-- 
Jason

[ message continues ]

correction: I can write a small file;
writing a 700mb avi stopped at byte 149495808, saying

$ mv thief.* /media/Mann/
mv: /media/Mann/thief.avi: Interrupted system call


[ message continues ]

And yet, if I first create an empty file of the desired name,
and then copy over it, it works just fine:

$ touch /media/Mann/thief.avi
$ cp thief.avi /media/Mann/thief.avi

But then 'mplayer /media/Mann/thief.avi'
gets stuck again. According to 'dtrace -p 768  -P syscall'
(where 768 is the player process), this is what's happening:
http://stare.cz/~hans/.tmp/bsdmacnfs.txt

I will look at a tcpdump of such NFS session.

[ message continues ]

Just a quick update with the Dec.6 amd64 snapshot, and the problem still
exists. I had hoped with some recent attention to nfs re: the systat -m
freeze that there might have been some movement on this one.

I had written a couple other replies previously that never made it to
list. Hope this one fares better.

Cheers,
-- 
Jason

[ message continues ]