ZFS + NFS problems
Hello People, I have a webserver with a ZFS pool for storing all the user data. So all the users have their own filesystem with a quota set. With exporting the system I ran into some problems with NFS though. At other machines I can mount the user specific shares resulting in an 80-line fstab per machine or mount a higher dir. But that last option results in all the dirs and files in it mapped to root. So is there a solution to that last problem or will I need to use something else? As the share also gets mounted with Linux machines a server-side solution is prefered. -- Greetings, Ruud Althuizen pgpG9kcbUFbFf.pgp Description: PGP signature
Re: NFS Problems/Questions
On Sat, Jun 30, 2007 at 07:33:19PM -0400, Jason Morgan wrote: > On Sat, Jun 23, 2007 at 07:42:24PM -0400, Jason Morgan wrote: > > On Sat, Jun 23, 2007 at 12:46:27PM -0700, Michael Smith wrote: > > > Hello Jason: > > > > > > On Jun 23, 2007, at 9:34 AM, Jason Morgan wrote: > > > > > > >I've been having some trouble with NFS performance for some time and > > > >now that class is out, I've had a bit of time to investigate but I'm > > > >stuck. Below are the details of my investigation. Hopefully, someone > > > >here can give me some advice. > > > > > > > >The basic problem is that my NFS performance is very slow. Right now, > > > >I am connecting two workstations to a NFS server, which has my home > > > >directory, etc, mounted. They are connected over a gigabit network > > > >(right now with mtu set to 7000, which is supported by all hardware -- > > > >changing it to 1500 has no effect on performance, which is > > > >strange). Each system is running 6.2-RELEASE or -STABLE. Each system > > > >is also using the following network card: > > > > > > > ># ifconfig sk0 > > > >sk0: flags=8843 mtu 7000 > > > >options=b > > > >inet 10.0.0.2 netmask 0xff00 broadcast 10.0.0.255 > > > >ether 00:17:9a:bb:05:87 > > > >media: Ethernet autoselect (1000baseTX > > >duplex,flag0,flag1>) > > > >status: active > > > > > > > ># dmesg | grep sk > > > >skc0: port 0xec00-0xecff mem > > > > 0xfdff8000-0xfdffbfff irq 18 at device 10.0 on pci0 > > > >skc0: DGE-530T Gigabit Ethernet Adapter rev. (0x9) > > > >sk0: on skc0 > > > >sk0: Ethernet address: 00:17:9a:XX:XX:XX > > > > > > > >## Server /etc/rc.conf settings > > > > > > > >rpcbind_enable="YES" > > > >rpc_lockd_enable="YES" > > > >rpc_statd_enable="YES" > > > >nfs_server_enable="YES" > > > >nfs_server_flags="-u -t -n 12" > > > >nfs_bufpackets="32" > > > >mountd_flags="-r" > > > > > > > > > > > >## Client /etc/rc.conf settings > > > > > > > >nfs_client_enable="YES" > > > >nfs_bufpackets="32" > > > >nfsiod_enable="YES" > > > >nfsiod_flags="-n 6" > > > >rpc_lockd_enable="YES" > > > >rpc_statd_enable="YES" > > > >rpcbind_enable="YES" > > > > > > > >## /etc/exports > > > > > > > >/usr -alldirs,maproot=root client1 client2 > > > > > > > > > > > >For performance benchmarking, I am using dd. Locally from the server, > > > >this is a representative result when writing a 1GB file: > > > > > > > >## Local write test (for an upper-bound on what to expect). > > > > > > > ># dd if=/dev/zero of=./nfs.dat bs=1024k count=1000 > > > >1000+0 records in > > > >1000+0 records out > > > >1048576000 bytes transferred in 19.580184 secs (53552919 bytes/sec) > > > > > > > >Connecting from a client (both clients get approximately the same > > > >results). > > > > > > > >## Remote connection (UDP), mounted in /etc/fstab as with flags: > > > >## rw,-U,-3,-r=32768,-w=32768 > > > > > > > ># dd if=/dev/zero of=./nfs.dat bs=1024k count=1000 > > > >1000+0 records in > > > >1000+0 records out > > > >1048576000 bytes transferred in 101.151139 secs (10366428 bytes/sec) > > > > > > > >## Remote connection (TCP), mounted in /etc/fstab as with flags: > > > >## rw,-T,-3,-r=32768,-w=32768 > > > > > > > ># dd if=/dev/zero of=./nfs.dat bs=1024k count=1000 > > > >1000+0 records in > > > >1000+0 records out > > > >1048576000 bytes transferred in 59.668585 secs (17573334 bytes/sec) > > > > > > > >As can be seen above, TCP is much faster than UPD. I have tried many > > > >different mount settings and these are the best results I could > > > >get. To test whether or not I have having network issues, I > > > >transferred the same nfs.dat file via a http connection and got > > > >~32MB/sec -- almost 2x the speed of the TCP NFS connection. 32MB/sec > > > >is about what I would expect given that my fastest write speed is > > > >~50MB/sec. > > > > > > > >At this point I am stumped. I have tried increasing/changing the > > > >number of nfsiod servers as well as nfs_bufpackets. No matter what > > > >settings I change, the results are always the same. I get only two > > > >errors, first on /var/log/messages on the server I have just begun > > > >seeing: > > > > > > > >Jun 22 21:13:47 crichton routed[666]: sendto(dc1, 224.0.0.2): > > > >Operation not permitted > > > >Jun 22 21:13:47 crichton routed[666]: sendto(sk0, 224.0.0.2): > > > >Operation not permitted > > > >Jun 22 21:13:50 crichton routed[666]: sendto(dc1, 224.0.0.2): > > > >Operation not permitted > > > >Jun 22 21:13:50 crichton routed[666]: sendto(sk0, 224.0.0.2): > > > >Operation not permitted > > > > > > > >This appeared after I added a route; however, I added the route after > > > >many of the tests were done. I get the same results now as before the > > > >new route. On one of the clients (the one running 6.2-RELEASE-p1), I > > > >also get a nasty error: > > > > > > > >nfs/tcp clnt: Error 60 reading socket, tearing down TCP connection > > > > > > > >This cropped up last night after I tweaked some settings. They h
Re: NFS Problems/Questions
On Sat, Jun 23, 2007 at 07:42:24PM -0400, Jason Morgan wrote: > On Sat, Jun 23, 2007 at 12:46:27PM -0700, Michael Smith wrote: > > Hello Jason: > > > > On Jun 23, 2007, at 9:34 AM, Jason Morgan wrote: > > > > >I've been having some trouble with NFS performance for some time and > > >now that class is out, I've had a bit of time to investigate but I'm > > >stuck. Below are the details of my investigation. Hopefully, someone > > >here can give me some advice. > > > > > >The basic problem is that my NFS performance is very slow. Right now, > > >I am connecting two workstations to a NFS server, which has my home > > >directory, etc, mounted. They are connected over a gigabit network > > >(right now with mtu set to 7000, which is supported by all hardware -- > > >changing it to 1500 has no effect on performance, which is > > >strange). Each system is running 6.2-RELEASE or -STABLE. Each system > > >is also using the following network card: > > > > > ># ifconfig sk0 > > >sk0: flags=8843 mtu 7000 > > >options=b > > >inet 10.0.0.2 netmask 0xff00 broadcast 10.0.0.255 > > >ether 00:17:9a:bb:05:87 > > >media: Ethernet autoselect (1000baseTX > >duplex,flag0,flag1>) > > >status: active > > > > > ># dmesg | grep sk > > >skc0: port 0xec00-0xecff mem > > > 0xfdff8000-0xfdffbfff irq 18 at device 10.0 on pci0 > > >skc0: DGE-530T Gigabit Ethernet Adapter rev. (0x9) > > >sk0: on skc0 > > >sk0: Ethernet address: 00:17:9a:XX:XX:XX > > > > > >## Server /etc/rc.conf settings > > > > > >rpcbind_enable="YES" > > >rpc_lockd_enable="YES" > > >rpc_statd_enable="YES" > > >nfs_server_enable="YES" > > >nfs_server_flags="-u -t -n 12" > > >nfs_bufpackets="32" > > >mountd_flags="-r" > > > > > > > > >## Client /etc/rc.conf settings > > > > > >nfs_client_enable="YES" > > >nfs_bufpackets="32" > > >nfsiod_enable="YES" > > >nfsiod_flags="-n 6" > > >rpc_lockd_enable="YES" > > >rpc_statd_enable="YES" > > >rpcbind_enable="YES" > > > > > >## /etc/exports > > > > > >/usr -alldirs,maproot=root client1 client2 > > > > > > > > >For performance benchmarking, I am using dd. Locally from the server, > > >this is a representative result when writing a 1GB file: > > > > > >## Local write test (for an upper-bound on what to expect). > > > > > ># dd if=/dev/zero of=./nfs.dat bs=1024k count=1000 > > >1000+0 records in > > >1000+0 records out > > >1048576000 bytes transferred in 19.580184 secs (53552919 bytes/sec) > > > > > >Connecting from a client (both clients get approximately the same > > >results). > > > > > >## Remote connection (UDP), mounted in /etc/fstab as with flags: > > >## rw,-U,-3,-r=32768,-w=32768 > > > > > ># dd if=/dev/zero of=./nfs.dat bs=1024k count=1000 > > >1000+0 records in > > >1000+0 records out > > >1048576000 bytes transferred in 101.151139 secs (10366428 bytes/sec) > > > > > >## Remote connection (TCP), mounted in /etc/fstab as with flags: > > >## rw,-T,-3,-r=32768,-w=32768 > > > > > ># dd if=/dev/zero of=./nfs.dat bs=1024k count=1000 > > >1000+0 records in > > >1000+0 records out > > >1048576000 bytes transferred in 59.668585 secs (17573334 bytes/sec) > > > > > >As can be seen above, TCP is much faster than UPD. I have tried many > > >different mount settings and these are the best results I could > > >get. To test whether or not I have having network issues, I > > >transferred the same nfs.dat file via a http connection and got > > >~32MB/sec -- almost 2x the speed of the TCP NFS connection. 32MB/sec > > >is about what I would expect given that my fastest write speed is > > >~50MB/sec. > > > > > >At this point I am stumped. I have tried increasing/changing the > > >number of nfsiod servers as well as nfs_bufpackets. No matter what > > >settings I change, the results are always the same. I get only two > > >errors, first on /var/log/messages on the server I have just begun > > >seeing: > > > > > >Jun 22 21:13:47 crichton routed[666]: sendto(dc1, 224.0.0.2): > > >Operation not permitted > > >Jun 22 21:13:47 crichton routed[666]: sendto(sk0, 224.0.0.2): > > >Operation not permitted > > >Jun 22 21:13:50 crichton routed[666]: sendto(dc1, 224.0.0.2): > > >Operation not permitted > > >Jun 22 21:13:50 crichton routed[666]: sendto(sk0, 224.0.0.2): > > >Operation not permitted > > > > > >This appeared after I added a route; however, I added the route after > > >many of the tests were done. I get the same results now as before the > > >new route. On one of the clients (the one running 6.2-RELEASE-p1), I > > >also get a nasty error: > > > > > >nfs/tcp clnt: Error 60 reading socket, tearing down TCP connection > > > > > >This cropped up last night after I tweaked some settings. They have > > >now been changed back, but I still get this error. The other client is > > >unaffected. > > > > > >I appreciate any help people can provide on tracking down the > > >issues. Sorry about the long email -- just trying to be thorough. Of > > >course, I've searched the Internet and can't find any c
Re: NFS Problems/Questions
On Sat, Jun 23, 2007 at 12:46:27PM -0700, Michael Smith wrote: > Hello Jason: > > On Jun 23, 2007, at 9:34 AM, Jason Morgan wrote: > > >I've been having some trouble with NFS performance for some time and > >now that class is out, I've had a bit of time to investigate but I'm > >stuck. Below are the details of my investigation. Hopefully, someone > >here can give me some advice. > > > >The basic problem is that my NFS performance is very slow. Right now, > >I am connecting two workstations to a NFS server, which has my home > >directory, etc, mounted. They are connected over a gigabit network > >(right now with mtu set to 7000, which is supported by all hardware -- > >changing it to 1500 has no effect on performance, which is > >strange). Each system is running 6.2-RELEASE or -STABLE. Each system > >is also using the following network card: > > > ># ifconfig sk0 > >sk0: flags=8843 mtu 7000 > >options=b > >inet 10.0.0.2 netmask 0xff00 broadcast 10.0.0.255 > >ether 00:17:9a:bb:05:87 > >media: Ethernet autoselect (1000baseTX >duplex,flag0,flag1>) > >status: active > > > ># dmesg | grep sk > >skc0: port 0xec00-0xecff mem > > 0xfdff8000-0xfdffbfff irq 18 at device 10.0 on pci0 > >skc0: DGE-530T Gigabit Ethernet Adapter rev. (0x9) > >sk0: on skc0 > >sk0: Ethernet address: 00:17:9a:XX:XX:XX > > > >## Server /etc/rc.conf settings > > > >rpcbind_enable="YES" > >rpc_lockd_enable="YES" > >rpc_statd_enable="YES" > >nfs_server_enable="YES" > >nfs_server_flags="-u -t -n 12" > >nfs_bufpackets="32" > >mountd_flags="-r" > > > > > >## Client /etc/rc.conf settings > > > >nfs_client_enable="YES" > >nfs_bufpackets="32" > >nfsiod_enable="YES" > >nfsiod_flags="-n 6" > >rpc_lockd_enable="YES" > >rpc_statd_enable="YES" > >rpcbind_enable="YES" > > > >## /etc/exports > > > >/usr -alldirs,maproot=root client1 client2 > > > > > >For performance benchmarking, I am using dd. Locally from the server, > >this is a representative result when writing a 1GB file: > > > >## Local write test (for an upper-bound on what to expect). > > > ># dd if=/dev/zero of=./nfs.dat bs=1024k count=1000 > >1000+0 records in > >1000+0 records out > >1048576000 bytes transferred in 19.580184 secs (53552919 bytes/sec) > > > >Connecting from a client (both clients get approximately the same > >results). > > > >## Remote connection (UDP), mounted in /etc/fstab as with flags: > >## rw,-U,-3,-r=32768,-w=32768 > > > ># dd if=/dev/zero of=./nfs.dat bs=1024k count=1000 > >1000+0 records in > >1000+0 records out > >1048576000 bytes transferred in 101.151139 secs (10366428 bytes/sec) > > > >## Remote connection (TCP), mounted in /etc/fstab as with flags: > >## rw,-T,-3,-r=32768,-w=32768 > > > ># dd if=/dev/zero of=./nfs.dat bs=1024k count=1000 > >1000+0 records in > >1000+0 records out > >1048576000 bytes transferred in 59.668585 secs (17573334 bytes/sec) > > > >As can be seen above, TCP is much faster than UPD. I have tried many > >different mount settings and these are the best results I could > >get. To test whether or not I have having network issues, I > >transferred the same nfs.dat file via a http connection and got > >~32MB/sec -- almost 2x the speed of the TCP NFS connection. 32MB/sec > >is about what I would expect given that my fastest write speed is > >~50MB/sec. > > > >At this point I am stumped. I have tried increasing/changing the > >number of nfsiod servers as well as nfs_bufpackets. No matter what > >settings I change, the results are always the same. I get only two > >errors, first on /var/log/messages on the server I have just begun > >seeing: > > > >Jun 22 21:13:47 crichton routed[666]: sendto(dc1, 224.0.0.2): > >Operation not permitted > >Jun 22 21:13:47 crichton routed[666]: sendto(sk0, 224.0.0.2): > >Operation not permitted > >Jun 22 21:13:50 crichton routed[666]: sendto(dc1, 224.0.0.2): > >Operation not permitted > >Jun 22 21:13:50 crichton routed[666]: sendto(sk0, 224.0.0.2): > >Operation not permitted > > > >This appeared after I added a route; however, I added the route after > >many of the tests were done. I get the same results now as before the > >new route. On one of the clients (the one running 6.2-RELEASE-p1), I > >also get a nasty error: > > > >nfs/tcp clnt: Error 60 reading socket, tearing down TCP connection > > > >This cropped up last night after I tweaked some settings. They have > >now been changed back, but I still get this error. The other client is > >unaffected. > > > >I appreciate any help people can provide on tracking down the > >issues. Sorry about the long email -- just trying to be thorough. Of > >course, I've searched the Internet and can't find any clear assistence > >on these issues. > > > >Cheers, > >~Jason > > > We use the following settings on a mail cluster that's pushing about > 50 MB/sec sustained. > > 10.211.1.213:/m0/mail/m0nfs > rw,tcp,intr,noatime,nfsv3,-w=65536,-r=65536 > > # NFS Server > rpcbind_enable="YES" > rpc_lockd
Re: NFS Problems/Questions
Hello Jason: On Jun 23, 2007, at 9:34 AM, Jason Morgan wrote: I've been having some trouble with NFS performance for some time and now that class is out, I've had a bit of time to investigate but I'm stuck. Below are the details of my investigation. Hopefully, someone here can give me some advice. The basic problem is that my NFS performance is very slow. Right now, I am connecting two workstations to a NFS server, which has my home directory, etc, mounted. They are connected over a gigabit network (right now with mtu set to 7000, which is supported by all hardware -- changing it to 1500 has no effect on performance, which is strange). Each system is running 6.2-RELEASE or -STABLE. Each system is also using the following network card: # ifconfig sk0 sk0: flags=8843 mtu 7000 options=b inet 10.0.0.2 netmask 0xff00 broadcast 10.0.0.255 ether 00:17:9a:bb:05:87 media: Ethernet autoselect (1000baseTX duplex,flag0,flag1>) status: active # dmesg | grep sk skc0: port 0xec00-0xecff mem 0xfdff8000-0xfdffbfff irq 18 at device 10.0 on pci0 skc0: DGE-530T Gigabit Ethernet Adapter rev. (0x9) sk0: on skc0 sk0: Ethernet address: 00:17:9a:XX:XX:XX ## Server /etc/rc.conf settings rpcbind_enable="YES" rpc_lockd_enable="YES" rpc_statd_enable="YES" nfs_server_enable="YES" nfs_server_flags="-u -t -n 12" nfs_bufpackets="32" mountd_flags="-r" ## Client /etc/rc.conf settings nfs_client_enable="YES" nfs_bufpackets="32" nfsiod_enable="YES" nfsiod_flags="-n 6" rpc_lockd_enable="YES" rpc_statd_enable="YES" rpcbind_enable="YES" ## /etc/exports /usr -alldirs,maproot=root client1 client2 For performance benchmarking, I am using dd. Locally from the server, this is a representative result when writing a 1GB file: ## Local write test (for an upper-bound on what to expect). # dd if=/dev/zero of=./nfs.dat bs=1024k count=1000 1000+0 records in 1000+0 records out 1048576000 bytes transferred in 19.580184 secs (53552919 bytes/sec) Connecting from a client (both clients get approximately the same results). ## Remote connection (UDP), mounted in /etc/fstab as with flags: ## rw,-U,-3,-r=32768,-w=32768 # dd if=/dev/zero of=./nfs.dat bs=1024k count=1000 1000+0 records in 1000+0 records out 1048576000 bytes transferred in 101.151139 secs (10366428 bytes/sec) ## Remote connection (TCP), mounted in /etc/fstab as with flags: ## rw,-T,-3,-r=32768,-w=32768 # dd if=/dev/zero of=./nfs.dat bs=1024k count=1000 1000+0 records in 1000+0 records out 1048576000 bytes transferred in 59.668585 secs (17573334 bytes/sec) As can be seen above, TCP is much faster than UPD. I have tried many different mount settings and these are the best results I could get. To test whether or not I have having network issues, I transferred the same nfs.dat file via a http connection and got ~32MB/sec -- almost 2x the speed of the TCP NFS connection. 32MB/sec is about what I would expect given that my fastest write speed is ~50MB/sec. At this point I am stumped. I have tried increasing/changing the number of nfsiod servers as well as nfs_bufpackets. No matter what settings I change, the results are always the same. I get only two errors, first on /var/log/messages on the server I have just begun seeing: Jun 22 21:13:47 crichton routed[666]: sendto(dc1, 224.0.0.2): Operation not permitted Jun 22 21:13:47 crichton routed[666]: sendto(sk0, 224.0.0.2): Operation not permitted Jun 22 21:13:50 crichton routed[666]: sendto(dc1, 224.0.0.2): Operation not permitted Jun 22 21:13:50 crichton routed[666]: sendto(sk0, 224.0.0.2): Operation not permitted This appeared after I added a route; however, I added the route after many of the tests were done. I get the same results now as before the new route. On one of the clients (the one running 6.2-RELEASE-p1), I also get a nasty error: nfs/tcp clnt: Error 60 reading socket, tearing down TCP connection This cropped up last night after I tweaked some settings. They have now been changed back, but I still get this error. The other client is unaffected. I appreciate any help people can provide on tracking down the issues. Sorry about the long email -- just trying to be thorough. Of course, I've searched the Internet and can't find any clear assistence on these issues. Cheers, ~Jason We use the following settings on a mail cluster that's pushing about 50 MB/sec sustained. 10.211.1.213:/m0/mail/m0nfs rw,tcp,intr,noatime,nfsv3,-w=65536,-r=65536 # NFS Server rpcbind_enable="YES" rpc_lockd_enable="YES" rpc_statd_enable="YES" nfs_server_enable="YES" nfs_server_flags="-u -t -n 16 -h 10.211.1.213" mountd_flags="-r" I would imagine the larger read/write values above would be fine for you as well, given you have Gigabit links. The 'noatime' setting may be problematic depending on your application. You might want to Google specifics on what applications use atime to see if that's a good flag for you or not. I'd love to see your resul
NFS Problems/Questions
I've been having some trouble with NFS performance for some time and now that class is out, I've had a bit of time to investigate but I'm stuck. Below are the details of my investigation. Hopefully, someone here can give me some advice. The basic problem is that my NFS performance is very slow. Right now, I am connecting two workstations to a NFS server, which has my home directory, etc, mounted. They are connected over a gigabit network (right now with mtu set to 7000, which is supported by all hardware -- changing it to 1500 has no effect on performance, which is strange). Each system is running 6.2-RELEASE or -STABLE. Each system is also using the following network card: # ifconfig sk0 sk0: flags=8843 mtu 7000 options=b inet 10.0.0.2 netmask 0xff00 broadcast 10.0.0.255 ether 00:17:9a:bb:05:87 media: Ethernet autoselect (1000baseTX ) status: active # dmesg | grep sk skc0: port 0xec00-0xecff mem 0xfdff8000-0xfdffbfff irq 18 at device 10.0 on pci0 skc0: DGE-530T Gigabit Ethernet Adapter rev. (0x9) sk0: on skc0 sk0: Ethernet address: 00:17:9a:XX:XX:XX ## Server /etc/rc.conf settings rpcbind_enable="YES" rpc_lockd_enable="YES" rpc_statd_enable="YES" nfs_server_enable="YES" nfs_server_flags="-u -t -n 12" nfs_bufpackets="32" mountd_flags="-r" ## Client /etc/rc.conf settings nfs_client_enable="YES" nfs_bufpackets="32" nfsiod_enable="YES" nfsiod_flags="-n 6" rpc_lockd_enable="YES" rpc_statd_enable="YES" rpcbind_enable="YES" ## /etc/exports /usr -alldirs,maproot=root client1 client2 For performance benchmarking, I am using dd. Locally from the server, this is a representative result when writing a 1GB file: ## Local write test (for an upper-bound on what to expect). # dd if=/dev/zero of=./nfs.dat bs=1024k count=1000 1000+0 records in 1000+0 records out 1048576000 bytes transferred in 19.580184 secs (53552919 bytes/sec) Connecting from a client (both clients get approximately the same results). ## Remote connection (UDP), mounted in /etc/fstab as with flags: ## rw,-U,-3,-r=32768,-w=32768 # dd if=/dev/zero of=./nfs.dat bs=1024k count=1000 1000+0 records in 1000+0 records out 1048576000 bytes transferred in 101.151139 secs (10366428 bytes/sec) ## Remote connection (TCP), mounted in /etc/fstab as with flags: ## rw,-T,-3,-r=32768,-w=32768 # dd if=/dev/zero of=./nfs.dat bs=1024k count=1000 1000+0 records in 1000+0 records out 1048576000 bytes transferred in 59.668585 secs (17573334 bytes/sec) As can be seen above, TCP is much faster than UPD. I have tried many different mount settings and these are the best results I could get. To test whether or not I have having network issues, I transferred the same nfs.dat file via a http connection and got ~32MB/sec -- almost 2x the speed of the TCP NFS connection. 32MB/sec is about what I would expect given that my fastest write speed is ~50MB/sec. At this point I am stumped. I have tried increasing/changing the number of nfsiod servers as well as nfs_bufpackets. No matter what settings I change, the results are always the same. I get only two errors, first on /var/log/messages on the server I have just begun seeing: Jun 22 21:13:47 crichton routed[666]: sendto(dc1, 224.0.0.2): Operation not permitted Jun 22 21:13:47 crichton routed[666]: sendto(sk0, 224.0.0.2): Operation not permitted Jun 22 21:13:50 crichton routed[666]: sendto(dc1, 224.0.0.2): Operation not permitted Jun 22 21:13:50 crichton routed[666]: sendto(sk0, 224.0.0.2): Operation not permitted This appeared after I added a route; however, I added the route after many of the tests were done. I get the same results now as before the new route. On one of the clients (the one running 6.2-RELEASE-p1), I also get a nasty error: nfs/tcp clnt: Error 60 reading socket, tearing down TCP connection This cropped up last night after I tweaked some settings. They have now been changed back, but I still get this error. The other client is unaffected. I appreciate any help people can provide on tracking down the issues. Sorry about the long email -- just trying to be thorough. Of course, I've searched the Internet and can't find any clear assistence on these issues. Cheers, ~Jason ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
NFS Problems
I'm all of a sudden having this error pop up: NFSPROC_NULL: RPC: Timed out Both servers have talked with each other before, and I just rebooted them both... What could be going on? ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: NFS problems!
Anders Troback <[EMAIL PROTECTED]> writes: > Hi, > > I'm having some problems with NFS lately! > > NFS server FreeBSD 6.1-RELESE > NFS client FreeBSD 6.2-PRERELASE (STABLE) > > I'm using NFS to serve /home via amd but sometimes programs hangs and > not even kill -9 will work. I have to restart rpc.lockd, rpc.statd and > nfsd to get rid of the programs! If one program hangs many will follow > and some will not start. Programs like Citrix Client Manager > (wfcmgr), konqueror, konsole and gftp are all examples on programs that > don't start. Sins 6.2-PRERELEASE sometimes wfcmgr don't start even if > there are no programs hanging! You're lucky. I can't even get X to load and the whole vfs won't shut down cleanly once I've tried. I have yet to try other FreeBSD releases though. Matthew -- I must take issue with the term "a mere child," for it has been my invariable experience that the company of a mere child is infinitely preferable to that of a mere adult. -- Fran Lebowitz ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: NFS problems!
Anders Troback <[EMAIL PROTECTED]> writes: > I'm having some problems with NFS lately! > > NFS server FreeBSD 6.1-RELESE > NFS client FreeBSD 6.2-PRERELASE (STABLE) > > I'm using NFS to serve /home via amd but sometimes programs hangs and > not even kill -9 will work. I have to restart rpc.lockd, rpc.statd and > nfsd to get rid of the programs! If one program hangs many will follow > and some will not start. Programs like Citrix Client Manager > (wfcmgr), konqueror, konsole and gftp are all examples on programs that > don't start. Sins 6.2-PRERELEASE sometimes wfcmgr don't start even if > there are no programs hanging! > > This problem first occurred in 6.1-STABLE but disappear in 6.1-RELEASE > and since 6.1-RELEASE-p4 (not 100% sure if it was p4 or p5) it's back! > > Does anyone have any idea what's going on here? There have been some discussions of locking problems; see the -net list. In this case, though, I would tend to go with a soft mount anyway, which might reduce the symptoms considerably. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
NFS problems!
Hi, I'm having some problems with NFS lately! NFS server FreeBSD 6.1-RELESE NFS client FreeBSD 6.2-PRERELASE (STABLE) I'm using NFS to serve /home via amd but sometimes programs hangs and not even kill -9 will work. I have to restart rpc.lockd, rpc.statd and nfsd to get rid of the programs! If one program hangs many will follow and some will not start. Programs like Citrix Client Manager (wfcmgr), konqueror, konsole and gftp are all examples on programs that don't start. Sins 6.2-PRERELEASE sometimes wfcmgr don't start even if there are no programs hanging! This problem first occurred in 6.1-STABLE but disappear in 6.1-RELEASE and since 6.1-RELEASE-p4 (not 100% sure if it was p4 or p5) it's back! Does anyone have any idea what's going on here? Thanks! Regards, Anders Trobäck Sweden -- How many Microsoft employees does it take to screw in a light bulb? None, they declare darkness a new standard. Anders Trobäck http://www.troback.com/ - ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Weird NFS problems
Jon Dama wrote: Yes, but surely you weren't bridging gigabit and 100Mbit before? Did you try my suggestion about binding the IP address of the NFS server to the 100Mbit side? Yeah. Unfortunately networking on the server fell apart when I did that. Traffic was still passed and I could get through to the server on the 100Mb/s side, but not on the 1000Mb/s. It looked like the arp tables weren't being forwarded properly, but I couldn't convince FreeBSD to do proxy arp. After doing some more poking around, it actually looks like it might be a misfeature in the Linux 2.4 kernel wrt ipfilter (which is running on the bridge). Apparently 2.4 fragments UDP packets in the reverse order that every other UNIX-like operating system does, which throws off ipfilter's state tables. I'm going to do some testing to see if the difference between UDP and TCP NFS is negligible enough for us to disregard. Thanks for the suggestions! -- -- Skylar Thompson ([EMAIL PROTECTED]) -- http://www.cs.earlham.edu/~skylar/ signature.asc Description: OpenPGP digital signature
Re: Weird NFS problems
Yes, but surely you weren't bridging gigabit and 100Mbit before? Did you try my suggestion about binding the IP address of the NFS server to the 100Mbit side? -Jon On Tue, 31 May 2005, Skylar Thompson wrote: > Jon Dama wrote: > > >Try switching to TCP NFS. > > > >a 100MBit interface cannot keep up with a 1GBit interface in a bridge > >configuration. Therefore, in the long run, at full-bore you'd expect to > >drop 9 out of every 10 ethernet frames. > > > >MTU is 1500 therefore 1K works (it fits in one frame), 2K doesn't (your > >NFS transactions are split across frames, one of which will almost > >certainly be dropped, it's UDP so the loss of one frame invalidates the > >whole transaction). > > > >This is the same reason you can't use UDP with a block size greater than > >MTU to use NFS over your DSL or some such arrangement. > > > >Incidentially, this has nothing to do with FreeBSD. So if using TCP > >mounts solves your problem, don't expect Solaris NFS to magically make the > >UDP case work... > > > > > > The thing is that UDP NFS has been working for us for years. A big part > of our work is performance analysis, so to change our network > architecture will invalidate a large part of our data. > > -- > -- Skylar Thompson ([EMAIL PROTECTED]) > -- http://www.cs.earlham.edu/~skylar/ > > ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Weird NFS problems
Jon Dama wrote: Try switching to TCP NFS. a 100MBit interface cannot keep up with a 1GBit interface in a bridge configuration. Therefore, in the long run, at full-bore you'd expect to drop 9 out of every 10 ethernet frames. MTU is 1500 therefore 1K works (it fits in one frame), 2K doesn't (your NFS transactions are split across frames, one of which will almost certainly be dropped, it's UDP so the loss of one frame invalidates the whole transaction). This is the same reason you can't use UDP with a block size greater than MTU to use NFS over your DSL or some such arrangement. Incidentially, this has nothing to do with FreeBSD. So if using TCP mounts solves your problem, don't expect Solaris NFS to magically make the UDP case work... The thing is that UDP NFS has been working for us for years. A big part of our work is performance analysis, so to change our network architecture will invalidate a large part of our data. -- -- Skylar Thompson ([EMAIL PROTECTED]) -- http://www.cs.earlham.edu/~skylar/ signature.asc Description: OpenPGP digital signature
Re: Weird NFS problems
Oh, something else to try: I checked through my notes and discovered that I had gotten UDP to work in a similar configuration before. What I did was bind the IP address to fxp0 instead of em0. By doing this, the kernel seems to send the data at a pace suitable for the slow interface. -Jon On Fri, 27 May 2005, Don Lewis wrote: > On 26 May, Skylar Thompson wrote: > > I'm having some problems with NFS serving on a FreeBSD 5.4-RELEASE > > machine. The FreeBSD machine is the NFS/NIS server for a group of four > > Linux clusters. The network archictecture looks like this: > > > > 234/24 234/24 > > Cluster 1 ---|--- Cluster 3 > >| --- > > em0| File server | fxp0 > >| -- > > Cluster 2 ---|--- Cluster 4 > > 234/24230/24 > > > > > > em0 and fxp0 are bridged, and em0 has a 234/24 IP address while fxp0 is > > just in promiscuous mode. 234/24 is an 802.1q VLAN on the fxp0 side of > > the server, so packets are untagged at the switch just before fxp0, and > > are forwarded to em0 through the bridge. > > > > The problem manifests itself in large UDP NFS requests from Clusters 3 > > and 4. The export can be mounted fine from both those clusters, and > > small transfers such as with ls work fine, but the moment any serious > > data transfer starts, the entire mount just hangs. Running ethereal on > > the file server shows a a lot of fragmented packets, and RPC > > retransmissions on just a single request. Reducing the read and write > > NFS buffers on the Linux clients to 1kB from the default of 4kB solves > > the issue, but kills the transfer rate. The moment I go to 2kB, the > > problem reappearss. Clusters 1 and 2 use the default of 4kB buffers, and > > have no problems communicating to em0. > > > > Poking through the list archives, I ran across this message > > (http://lists.freebsd.org/pipermail/freebsd-stable/2003-May/001007.html) > > that reveals a bug in the fxp(4) driver in 4-RELEASE that incorrectly > > detects the capabilities of the NIC. Is this still an issue in > > 5-RELEASE, or am I looking at a different problem? Any ideas on how I > > can get the NFS buffers up to a reasonable level? > > That problem was fixed quite some time ago. > > Which transfer direction fails? > Client writing to server > Client reading from server > Both? > > Do you see all the fragments in the retransmitted request? > > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Weird NFS problems
Try switching to TCP NFS. a 100MBit interface cannot keep up with a 1GBit interface in a bridge configuration. Therefore, in the long run, at full-bore you'd expect to drop 9 out of every 10 ethernet frames. MTU is 1500 therefore 1K works (it fits in one frame), 2K doesn't (your NFS transactions are split across frames, one of which will almost certainly be dropped, it's UDP so the loss of one frame invalidates the whole transaction). This is the same reason you can't use UDP with a block size greater than MTU to use NFS over your DSL or some such arrangement. Incidentially, this has nothing to do with FreeBSD. So if using TCP mounts solves your problem, don't expect Solaris NFS to magically make the UDP case work... -Jon On Fri, 27 May 2005, Don Lewis wrote: > On 26 May, Skylar Thompson wrote: > > I'm having some problems with NFS serving on a FreeBSD 5.4-RELEASE > > machine. The FreeBSD machine is the NFS/NIS server for a group of four > > Linux clusters. The network archictecture looks like this: > > > > 234/24 234/24 > > Cluster 1 ---|--- Cluster 3 > >| --- > > em0| File server | fxp0 > >| -- > > Cluster 2 ---|--- Cluster 4 > > 234/24230/24 > > > > > > em0 and fxp0 are bridged, and em0 has a 234/24 IP address while fxp0 is > > just in promiscuous mode. 234/24 is an 802.1q VLAN on the fxp0 side of > > the server, so packets are untagged at the switch just before fxp0, and > > are forwarded to em0 through the bridge. > > > > The problem manifests itself in large UDP NFS requests from Clusters 3 > > and 4. The export can be mounted fine from both those clusters, and > > small transfers such as with ls work fine, but the moment any serious > > data transfer starts, the entire mount just hangs. Running ethereal on > > the file server shows a a lot of fragmented packets, and RPC > > retransmissions on just a single request. Reducing the read and write > > NFS buffers on the Linux clients to 1kB from the default of 4kB solves > > the issue, but kills the transfer rate. The moment I go to 2kB, the > > problem reappearss. Clusters 1 and 2 use the default of 4kB buffers, and > > have no problems communicating to em0. > > > > Poking through the list archives, I ran across this message > > (http://lists.freebsd.org/pipermail/freebsd-stable/2003-May/001007.html) > > that reveals a bug in the fxp(4) driver in 4-RELEASE that incorrectly > > detects the capabilities of the NIC. Is this still an issue in > > 5-RELEASE, or am I looking at a different problem? Any ideas on how I > > can get the NFS buffers up to a reasonable level? > > That problem was fixed quite some time ago. > > Which transfer direction fails? > Client writing to server > Client reading from server > Both? > > Do you see all the fragments in the retransmitted request? > > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Weird NFS problems
On 26 May, Skylar Thompson wrote: > I'm having some problems with NFS serving on a FreeBSD 5.4-RELEASE > machine. The FreeBSD machine is the NFS/NIS server for a group of four > Linux clusters. The network archictecture looks like this: > > 234/24 234/24 > Cluster 1 ---|--- Cluster 3 >| --- > em0| File server | fxp0 >| -- > Cluster 2 ---|--- Cluster 4 > 234/24230/24 > > > em0 and fxp0 are bridged, and em0 has a 234/24 IP address while fxp0 is > just in promiscuous mode. 234/24 is an 802.1q VLAN on the fxp0 side of > the server, so packets are untagged at the switch just before fxp0, and > are forwarded to em0 through the bridge. > > The problem manifests itself in large UDP NFS requests from Clusters 3 > and 4. The export can be mounted fine from both those clusters, and > small transfers such as with ls work fine, but the moment any serious > data transfer starts, the entire mount just hangs. Running ethereal on > the file server shows a a lot of fragmented packets, and RPC > retransmissions on just a single request. Reducing the read and write > NFS buffers on the Linux clients to 1kB from the default of 4kB solves > the issue, but kills the transfer rate. The moment I go to 2kB, the > problem reappearss. Clusters 1 and 2 use the default of 4kB buffers, and > have no problems communicating to em0. > > Poking through the list archives, I ran across this message > (http://lists.freebsd.org/pipermail/freebsd-stable/2003-May/001007.html) > that reveals a bug in the fxp(4) driver in 4-RELEASE that incorrectly > detects the capabilities of the NIC. Is this still an issue in > 5-RELEASE, or am I looking at a different problem? Any ideas on how I > can get the NFS buffers up to a reasonable level? That problem was fixed quite some time ago. Which transfer direction fails? Client writing to server Client reading from server Both? Do you see all the fragments in the retransmitted request? ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Weird NFS problems
I'm having some problems with NFS serving on a FreeBSD 5.4-RELEASE machine. The FreeBSD machine is the NFS/NIS server for a group of four Linux clusters. The network archictecture looks like this: 234/24 234/24 Cluster 1 ---|--- Cluster 3 | --- em0| File server | fxp0 | -- Cluster 2 ---|--- Cluster 4 234/24230/24 em0 and fxp0 are bridged, and em0 has a 234/24 IP address while fxp0 is just in promiscuous mode. 234/24 is an 802.1q VLAN on the fxp0 side of the server, so packets are untagged at the switch just before fxp0, and are forwarded to em0 through the bridge. The problem manifests itself in large UDP NFS requests from Clusters 3 and 4. The export can be mounted fine from both those clusters, and small transfers such as with ls work fine, but the moment any serious data transfer starts, the entire mount just hangs. Running ethereal on the file server shows a a lot of fragmented packets, and RPC retransmissions on just a single request. Reducing the read and write NFS buffers on the Linux clients to 1kB from the default of 4kB solves the issue, but kills the transfer rate. The moment I go to 2kB, the problem reappearss. Clusters 1 and 2 use the default of 4kB buffers, and have no problems communicating to em0. Poking through the list archives, I ran across this message (http://lists.freebsd.org/pipermail/freebsd-stable/2003-May/001007.html) that reveals a bug in the fxp(4) driver in 4-RELEASE that incorrectly detects the capabilities of the NIC. Is this still an issue in 5-RELEASE, or am I looking at a different problem? Any ideas on how I can get the NFS buffers up to a reasonable level? -- -- Skylar Thompson ([EMAIL PROTECTED]) -- http://www.cs.earlham.edu/~skylar/ signature.asc Description: OpenPGP digital signature
Re: NFS problems
Karel Miklav wrote: > I have a FreeBSD 5.3RC1 and Mandrake 10 Connected over NFS. Server is on > Mandrake and FreeBSD is only client. Transfer rate for files is great, > but scanning folders on the NFS mount is ubearably slow. CPU usage on > both machines is close to 0%, on Mandrake I can see a nfsd daemon or two > fired up from time to time, client is waiting in the loop. Might it be that you are having issues with different MTU size? -- Jakob Breivik Grimstveit, http://www.grimstveit.no/jakob, +47 48298152 Bruk Newsergalleriet! No på http://www.newsergalleriet.no/ Treng du noko på CD?: http://www.grimstveit.no/jakob/burncd_no ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
NFS problems
I have a FreeBSD 5.3RC1 and Mandrake 10 Connected over NFS. Server is on Mandrake and FreeBSD is only client. Transfer rate for files is great, but scanning folders on the NFS mount is ubearably slow. CPU usage on both machines is close to 0%, on Mandrake I can see a nfsd daemon or two fired up from time to time, client is waiting in the loop. What could be wrong? Regards, Karel ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: NFS problems
On Wed, Jul 09, 2003 at 04:45:38PM -0700, Mark Woodson wrote: > It's acting like the problem is in /etc/exports. > > squelcher# less /etc/exports > /usr/src-ro -maproot=0 cad1 squelcher lappy > /usr/obj-ro -maproot=0 cad1 squelcher lappy You export the actual local mount (i.e. if /usr is a mount on the NFSd machine) and then define the directories you want to share, i.e.: /usr/usr/src-ro -maproot=0 cad1 squelcher lappy /usr/usr/obj-ro -maproot=0 cad1 squelcher lappy I think that's how it goes, anyway. Best wishes, -lewiz. -- Acquaintance, n.: A person whom we know well enough to borrow from, but not well enough to lend to. -- Ambrose Bierce, "The Devil's Dictionary" -| msn:[EMAIL PROTECTED] | jab:[EMAIL PROTECTED] | url:http://lewiz.net |- pgp0.pgp Description: PGP signature
Re: NFS problems
On Wed, Jul 09, 2003 at 04:45:38PM -0700, Mark Woodson wrote: > I'm having trouble getting NFS exports to work properly on FreeBSD. I'm > running 4.8-STABLE as of July 3. > > It's acting like the problem is in /etc/exports. > > squelcher# less /etc/exports > /usr/src-ro -maproot=0 cad1 squelcher lappy > /usr/obj-ro -maproot=0 cad1 squelcher lappy Try placing both fs on the same line: /usr/src /usr/obj -ro -maproot=0 cad1 squelcher lappy Mount points that reside on the same filesystem (ie both on /usr in this case) have to be listed in the same entry in /etc/exports iirc. This is probably why you get the error: > Jul 9 13:09:00 squelcher mountd[16110]: can't change attributes for /usr/obj > Jul 9 13:09:00 squelcher mountd[16110]: bad exports list line /usr/obj -ro > -maproot ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
NFS problems
I'm having trouble getting NFS exports to work properly on FreeBSD. I'm running 4.8-STABLE as of July 3. It's acting like the problem is in /etc/exports. squelcher# less /etc/exports /usr/src-ro -maproot=0 cad1 squelcher lappy /usr/obj-ro -maproot=0 cad1 squelcher lappy /usr/src will export and is mountable /usr/obj is not squelcher# ls -ls /usr total 54 [edited for brevity] 2 drwxr-xr-x 3 root wheel 512 Jun 5 10:45 obj 2 drwxr-xr-x 21 root wheel 512 Jun 9 15:54 src on squelcher (the nfs server) I see this in messages when I start/sighup mountd. squelcher# tail /var/log/messages Jul 9 13:09:00 squelcher mountd[16110]: can't change attributes for /usr/obj Jul 9 13:09:00 squelcher mountd[16110]: bad exports list line /usr/obj -ro -maproot Jul 9 13:09:29 squelcher mountd[16110]: mount request denied from 10.1.2.60 for /usr/obj and "Access denied" messages on lappy (the nfs client). The permissions look the same, the exports lines are the same, and I must be missing something but I can't figure out what it is. -Mark ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: NFS Problems...
> There shouldn't BE a /home2 on HTTPD but I figured out what > happened. I > copied /etc/group /etc/passwd /etc/pwd.db > and /etc/master.passwd from NFSD > to HTTPD to sync users and passwords and forgot to edit the > home dir with > vipw. I just did a global search and replace of /home2 to /home > and > rebuilt the pwd.db and it mounted fine and apache now > serves "public_html" > from the users shells. > However, on reboot it doesn't mount from /etc/fstab, I have to mount it > manually for some reason. So now I'm down to the one NFS problem. > on NFSD: (/etc/exports) > /home2 -maproot=0 -alldirs httpd > on HTTPD: (/etc/fstab) > NFSD:/home2 /home nfs rw,bg 0 0 > > mount NFSD:/home2 /home > Works fine until I reboot. Shouldn't it mount by itself like it used to? > What am I missing now? Why doesn't HTTPD mount > NFSD:/home2 on /home when > it reboots? > TIA Hi, In your fstab, what is the "bg" purpose ? I never seen this option before. Make sure such option is usable. Pote ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: NFS Problems...
On Thu, Jun 05, 2003 at 01:03:17AM +0200 or thereabouts, Bernd Walter seemed to write: > On Wed, Jun 04, 2003 at 02:21:29PM -0700, jle wrote: > > I retired my old p200 fbsd 4.4-stable web server and built a newer box for > > it. I used to mount the /home2 dir from my nfs server (fbsd 5.1-current) > > to /home on the webserver and it used to work fine but now it doesn't > > mount /home2 on /home on boot up. I can manually mount it but then it > > gets confused and thinks it's mounted on /home2 when it's not. Evidently > > something must have changed since 4.4-S because it worked until today. > > > > on NFSD: (/etc/exports) > > /home2 -maproot=0 -alldirs httpd > > > > on HTTPD: (/etc/fstab) > > NFSD:/home2 /home nfs rw,bg 0 0 > > > > > > mount NFSD:/home2 /home > > > > [EMAIL PROTECTED]:~ -13:55:06- # cd ~dkdesign > > -su: cd: /home2/dkdesign: No such file or directory > > Not surprising, because you mounted on /home not /home2. > > > [EMAIL PROTECTED]:~ -13:58:45- # cd /home/dkdesign/ > > [EMAIL PROTECTED]:/home/dkdesign -14:02:21- # ls -al > > drwxr-xr-x 2 dkdesign dkdesign 512 Mar 13 09:15 public_html/ > > Yes - that's /home, only /home2 is failing... > Works as designed. > > > >From /var/log/httpd-error.log: > > [Wed Jun 4 13:56:45 2003] [error] [client xxx.xxx.xxx.xxx] File does not > > exist: /home2/dkdesigns/public_html/ > > > > I don't get it. Any help? > > ed /etc/fstab > /home2 > s/home/home2/ This should be s/home2/home/ or it'll have a line with "home22" -- Josh > w > q > > -- > B.Walter BWCThttp://www.bwct.de > [EMAIL PROTECTED] [EMAIL PROTECTED] > > ___ > [EMAIL PROTECTED] mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
NFS problems -- performance degraded after upgrade to 4.7
Hello all, I'm having some problems with nfs performance. Here is a bit of background. I have a fileserver running FreeBSD 4.7-STABLE. This has a 3ware Escalade with 4 x 80GB Maxtors in a RAID 5 config. I am exporting /usr/ports, among other things - 5 exports total to 2 clients. The clients are all running 4.7-Stable as well. Under 4.6.2, I was able to install ports with no problems on the clients. Now, patches don't seem to always work, files aren't always getting created, and 'Server Ret-Failed' from nfsstat -s increments quite rapidly. I hope there isn't any problems following this. # relevant info section: ###Fileserver### 13:41:51:d_jab@aluminum (/dev/ttyp5): 15 ~ grep nfs /etc/rc.conf nfs_reserved_port_only="YES" nfs_server_enable="YES" nfs_server_flags="-u -t -n 20 -h 192.168.23.200" 13:40:12:d_jab@aluminum (/dev/ttyp5): 12 ~ grep twed /etc/fstab /dev/twed0s1b noneswapsw 0 0 /dev/twed0s1h /home ufs rw,noatime,nosuid,nodev 2 2 /dev/twed0s1e /usrufs rw,noatime 2 2 /dev/twed0s1d /usr/local/mp3 ufs rw,noatime,nosuid,nodev 2 2 /dev/twed0s1a /usr/local/storage ufs rw,noatime 2 2 /dev/twed0s1g /usr/ports ufs rw,noatime 2 2 /dev/twed0s1f /usr/srcufs rw,noatime 2 2 13:40:23:d_jab@aluminum (/dev/ttyp5): 13 ~ cat /etc/exports /usr/src-maproot=root -network 192.168.23 -mask 255.255.255.0 /usr/ports -maproot=root -network 192.168.23 -mask 255.255.255.0 /home -maproot=root -network 192.168.23 -mask 255.255.255.0 /usr/local/mp3 -maproot=root -network 192.168.23 -mask 255.255.255.0 /usr/local/storage -maproot=root -network 192.168.23 -mask 255.255.255.0 13:40:58:d_jab@aluminum (/dev/ttyp5): 14 ~ nfsstat -s Server Info: Getattr SetattrLookup Readlink Read WriteCreate Remove 5749 6717648013560191927114932 40335 15174 Rename Link Symlink Mkdir Rmdir Readdir RdirPlus Access 23627 9 192 909 73947 40300 661793 MknodFsstatFsinfo PathConfCommitGLeaseVacate Evict 0 5311810 0 53650 0 0 0 Server Ret-Failed 242570 Server Faults 0 Server Cache Stats: Inprog Idem Non-idemMisses 0 4 0 803 Server Lease Stats: Leases PeakL GLeases 0 0 0 Server Write Gathering: WriteOps WriteRPC Opsaved 11490611493226 ## Client ## 13:43:50:d_jab@carbon (/dev/ttyp2): 6 ~ grep nfs /etc/rc.conf nfs_reserved_port_only="YES" nfs_client_enable="YES" nfs_client_flags="-n 6" 12:59:55:d_jab@carbon (/dev/ttyp2): 4 ~ grep nfs /etc/fstab al:/home/home nfs rw,nfsv3,tcp,intr,bg,rdirplus,noatime,-r=32768,-w=32768 00 al:/usr/ports /usr/ports nfs rw,nfsv3,tcp,intr,bg,rdirplus,noatime,-r=32768,-w=327680 0 al:/usr/src /usr/srcnfs rw,nfsv3,tcp,intr,bg,rdirplus,noatime,-r=32768,-w=327680 0 al:/usr/local/mp3 /usr/local/mp3 nfs rw,nfsv3,tcp,intr,bg,rdirplus,noatime,-r=32768,-w=32768 00 al:/usr/local/storage /usr/local/storage nfs rw,nfsv3,tcp,intr,bg,rdirplus,noatime,-r=32768,-w=327680 0 13:42:42:d_jab@carbon (/dev/ttyp2): 5 ~ nfsstat -c Client Info: Rpc Counts: Getattr SetattrLookup Readlink Read WriteCreate Remove 27410045059600363209637193806 55717 26701 Rename Link Symlink Mkdir Rmdir Readdir RdirPlus Access 2993927 195 1088 1084 0 43879 774525 MknodFsstatFsinfo PathConfCommitGLeaseVacate Evict 0 5665116 0 41432 0 0 0 Rpc Info: TimedOut Invalid X Replies Retries Requests 0 010 617 2131487 Cache Info: Attr HitsMisses Lkup HitsMisses BioR HitsMisses BioW Hits Misses 8475243579261 2735547595897 4225460198743320897 193806 BioRLHitsMisses BioD HitsMisses DirE HitsMisses 71863 69134 41254 5036714 # Does anyone have any advice? Let me know if you need more info. Thanks .daniel To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-questions" in the body of the message
Re: NFS Problems FreeBSD --> Solaris
;), Thu, Sep 19, 2002 at 05:58:43PM +, Weston M. Price said that hi all i have several problem but with IPv6 my box and solaris box was comunicationg with IPv6 but nfs not ;( try to set IPs in IPv4 format not IPv6 or hostname for example mount not for kripel.studnet.sk but 193.87.12.67 and so on > Hello, > I am attempting to mount a few directories from my Solaris machine(s) to my > FreeBSD workstation. nfsd is clearly running on Solaris and the sharing the > directories is not a problem. When I attempt to mount the directories on > FreeBSD I get the following error: > > damascus:/usr/wmprice: RPCMNT: clnt_create: RPC: Program not registered that's it send me your /etc/exports if i'm wrong replace hostnames and get there IPv4 adreses > A simple ps -x | egrep shows that nfsiod is running > > ps -x | egrep nfsiod > > 98 ?? I 0:00.00 nfsiod -n 4 > 99 ?? I 0:00.00 nfsiod -n 4 > 100 ?? I 0:00.00 nfsiod -n 4 > 101 ?? I 0:00.00 nfsiod -n 4 > > I have this configured to begin at startup. > > So, what am I doing wrong? This would seem to me to be a pretty simple > procedure. Any help would be appreciated. > > Weston > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-questions" in the body of the message\ bye -- 17:08 up 3 days, 19:49, 16 users, load averages: 0,15 0,07 0,02 -- FreeBSD 5.0-CURRENT #15: root@kripel:/usr/src/sys/i386/compile/angel -- powered by [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-questions" in the body of the message
Re: NFS Problems FreeBSD --> Solaris
> Hello, > I am attempting to mount a few directories from my Solaris machine(s) to my > > FreeBSD workstation. nfsd is clearly running on Solaris and the sharing the > directories is not a problem. When I attempt to mount the directories on > FreeBSD I get the following error: > > damascus:/usr/wmprice: RPCMNT: clnt_create: RPC: Program not registered It sounds like a) portmap isn't running, b) mountd is not registered with portmap (on the server) or is not running or c) nfsd is not running or registered with portmap (on the server). Confirm portmap is running on both hosts. If 'rpcinfo -p ' returns an error then portmap is not running. Run 'rpcinfo -p ' for both machines, check for mountd and check for nfsd Here is output from my local box (which exports my home dir) : rpcinfo -p localhost program vers proto port 102 tcp111 portmapper 102 udp111 portmapper 172 udp 1010 ypbind 172 tcp 1023 ypbind 153 udp 1006 mountd <-- 153 tcp 1022 mountd <-- 151 udp 1006 mountd <-- 151 tcp 1022 mountd <-- 132 udp 2049 nfs <-- 133 udp 2049 nfs <-- 1000241 udp996 status 1000241 tcp 1021 status 3000191 tcp 1019 3000191 udp991 Here is output from my solaris box rpcinfo -p solarisfs1 program vers proto port 104 tcp111 portmapper 103 tcp111 portmapper 102 tcp111 portmapper 104 udp111 portmapper 103 udp111 portmapper 102 udp111 portmapper 173 udp 32774 ypbind 172 udp 32774 ypbind 171 udp 32774 ypbind 173 tcp 32771 ypbind 172 tcp 32771 ypbind 171 tcp 32771 ypbind 1000241 udp 32782 status 1000241 tcp 32772 status 1001331 udp 32782 1001331 tcp 32772 1000211 udp 4045 nlockmgr 1000212 udp 4045 nlockmgr 1000213 udp 4045 nlockmgr 1000214 udp 4045 nlockmgr 1000211 tcp 4045 nlockmgr 1000212 tcp 4045 nlockmgr 1000213 tcp 4045 nlockmgr 1000214 tcp 4045 nlockmgr 3901131 tcp 7937 3901032 tcp 7939 3901092 tcp 7939 3901101 tcp 7939 3901032 udp 7940 3901092 udp 7940 3901101 udp 7940 151 udp 32877 mountd <-- 152 udp 32877 mountd <-- 153 udp 32877 mountd <-- 151 tcp 32881 mountd <-- 152 tcp 32881 mountd <-- 153 tcp 32881 mountd <-- 132 udp 2049 nfs <-- 133 udp 2049 nfs <-- 1002272 udp 2049 1002273 udp 2049 132 tcp 2049 nfs <-- 133 tcp 2049 nfs <-- 1002272 tcp 2049 1002273 tcp 2049 3000191 tcp 32930 3000191 udp 32888 3901074 tcp 7940 3901075 tcp 7940 390104 105 tcp 7941 3901055 tcp 7942 To confirm exports (shares) you can also run showmount showmount -e localhost Exports list on localhost: /export/u1 192.168.0.0 hosta.domain hostb.domain showmount -e solarisfs1 Exports list on solarisfs1: /export/u1 Everyone /package Everyone /foo Everyone To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-questions" in the body of the message
Re: NFS Problems FreeBSD --> Solaris
In the last episode (Sep 19), Weston M. Price said: > I am attempting to mount a few directories from my Solaris > machine(s) to my FreeBSD workstation. nfsd is clearly running on > Solaris and the sharing the directories is not a problem. When I > attempt to mount the directories on FreeBSD I get the following > error: > > damascus:/usr/wmprice: RPCMNT: clnt_create: RPC: Program not registered Make sure rpcbind, mountd, and nfsd are running on the Solaris box. If they are, what does the output of "rpcinfo -p damanscus" print? -- Dan Nelson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-questions" in the body of the message
NFS Problems FreeBSD --> Solaris
Hello, I am attempting to mount a few directories from my Solaris machine(s) to my FreeBSD workstation. nfsd is clearly running on Solaris and the sharing the directories is not a problem. When I attempt to mount the directories on FreeBSD I get the following error: damascus:/usr/wmprice: RPCMNT: clnt_create: RPC: Program not registered A simple ps -x | egrep shows that nfsiod is running ps -x | egrep nfsiod 98 ?? I 0:00.00 nfsiod -n 4 99 ?? I 0:00.00 nfsiod -n 4 100 ?? I 0:00.00 nfsiod -n 4 101 ?? I 0:00.00 nfsiod -n 4 I have this configured to begin at startup. So, what am I doing wrong? This would seem to me to be a pretty simple procedure. Any help would be appreciated. Weston To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-questions" in the body of the message
