Re: nfs tranfers hang in state getblck or nfsread

2003-08-29 Thread Terry Lambert
Jason Stone wrote:
 We actually had this discussion already over on -performance (and I get
 what you're saying), but the interesting question here is, why is 5.1
 behaving so differently from 4-stable on identical hardware under
 identical load.

Because an absolute ton of code was rewritten.

Try the following, if you have a cheked out 5.1 system from a local
copy of the repository via cvsup:

cd /usr/src
cvs diff -r RELENG_4 | wc -l

This will tell you how many lines of changes there are, not
including completely new files.

Be prepared to wait an hour or so while it spews the diffs.  8-).

-- Terry
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: nfs tranfers hang in state getblck or nfsread

2003-08-29 Thread Terry Lambert
Pawel Worach wrote:
 Here is some more information.
 I realized that i had tcp and udp blackholing enabled on the server so i
 disabled that, still no dice.
 disabled rpc.statd and rpc.lockd, still no dice.
[ ... ]
 So it looks like what i said before, only tcp seems to cause this.

I am now going to predict that your ethernet is multihomed,
and that you have more than one IP address on the server, the
client, or both.

8-).

-- Terry
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: nfs tranfers hang in state getblck or nfsread

2003-08-29 Thread Pawel Worach
Terry Lambert wrote:
I am now going to predict that your ethernet is multihomed,
and that you have more than one IP address on the server, the
client, or both.
That is true, I de-multihomed the server but the problem persists.
The client is not multihomed. The server also has INET6 in the kernel
the client does not.
	- Pawel

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: nfs tranfers hang in state getblck or nfsread

2003-08-28 Thread Jason Stone
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


 In this configuration I see a lot of nfs server ...: is not responding
 and nfs server ...: is alive again when I copy large files (e.g. a CD
 image). All of them happen in the same second. I haven't looked at the
 state or priority of the cp process when this happens.

I'm also seeing a similar problem - I have a cluster of high-volume
mailservers delivering mail over nfs to maildirs on a netapp.  The cluster
was all 4-stable, but I decided to mix a couple of 5.1 boxes in to see how
they would do.

The 5.1 boxes accepted and queued mail as well as the 4-stable boxes, but
delivering the mail into the maildirs over nfs, I kept seeing those
short-lived hangs, and so the queues started to back up as the boxes were
accepting mail faster than they could deliver it.

My mounts are all nfsv3 over udp.


 -Jason

 --
 Freud himself was a bit of a cold fish, and one cannot avoid the suspicion
 that he was insufficiently fondled when he was an infant.
-- Ashley Montagu
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.1 (FreeBSD)
Comment: See https://private.idealab.com/public/jason/jason.gpg

iD8DBQE/TYRhswXMWWtptckRAl7XAKDqAe2Z3HnT7bb+J6gPchMfxGo2fQCaA8u0
8wKNDwTh8NIFkLUNdi2HV2Q=
=g19M
-END PGP SIGNATURE-
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: nfs tranfers hang in state getblck or nfsread

2003-08-28 Thread Alexander Leidinger
On Wed, 27 Aug 2003 09:06:41 -0400 (EDT)
Robert Watson [EMAIL PROTECTED] wrote:

 I have a very similar configuration, but it sounds like I'm not bumping
 into the same problem.  Are you using NFSv2 or v3, and how many file
 systems are you mounting?  Are you generally using UFS1 or UFS2?  Right
 now, I'm mounting a single UFS2 file system was the root, and I believe
 right now we always mount NFS roots at NFSv2, which could by why I'm not
 seeing the same problem...

/dev/ad0s2e /big ufs rw1 2
Andro-Beta:/big/mp3 /big/mp3 nfs rw,soft,intr,tcp -b,-w=32768,-r=32768 0 0
Andro-Beta:/big/pics/big/picsnfs rw,soft,intr,tcp -b,-w=32768,-r=32768 0 0
Andro-Beta:/big/Windows /big/Windows nfs rw,soft,intr,tcp -b,-w=32768,-r=32768 0 0

Andro-Beta is a 4.8 system.

Bye,
Alexander.

-- 
Failure is not an option. It comes bundled with your Microsoft product.

http://www.Leidinger.net   Alexander @ Leidinger.net
  GPG fingerprint = C518 BC70 E67F 143F BE91  3365 79E2 9C60 B006 3FE7
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: nfs tranfers hang in state getblck or nfsread

2003-08-28 Thread Terry Lambert
Robert Watson wrote:
 I have a very similar configuration, but it sounds like I'm not bumping
 into the same problem.  Are you using NFSv2 or v3, and how many file
 systems are you mounting?  Are you generally using UFS1 or UFS2?  Right
 now, I'm mounting a single UFS2 file system was the root, and I believe
 right now we always mount NFS roots at NFSv2, which could by why I'm not
 seeing the same problem...

You're probably not using UDP; he might be...

-- Terry
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: nfs tranfers hang in state getblck or nfsread

2003-08-28 Thread Terry Lambert
Pawel Worach wrote:
[ ... subject ... ]

 This only seem to happen for nfs over tcp.

That's strange; most of the problems I've ever seen are from
using UDP, large read/write sizes, and then droping one packet
out of a bunch of frags caused by the MTU being much smaller
than the read/write size (misguided attempt to emulate a fixed
window size and get more packets in flight, without using TCP
to do it).


 fstab on the client (/conf/default/etc/fstab) looks like:
 server:/export/root   /   nfs ro  0   0
 procfs  /proc   procfs  rw  0   0
 server:/usr   /usrnfs ro,nfsv3,tcp0   0
 server:/usr/home  /home   nfs rw,nfsv3,tcp0   0
 /export nfs ro,nfsv3,tcp0   0
 server:/export/data/swap  /swap   nfs rw,nfsv3,tcp0   0
 /dev/acd0   /cdrom  cd9660  ro,noauto   0   0
 
 /etc/exports on the server looks like:
 /export -alldirs -maproot=root -network 192.168.1.0 -mask 255.255.255.0
 /export/root -ro -maproot=0 client
 /export/data/swap -mapall=nobody -network 192.168.1.0 -mask 255.255.255.0
 /usr/home client
 /usr -ro -network 192.168.1.0 -mask 255.255.255.0
 
 filesystems on the server:
 /magic   11954 (UFS1)timeWed Aug 27 17:34:13 2003
 /usr magic   19540119 (UFS2) timeWed Aug 27 17:33:38 2003
 /export magic   11954 (UFS1)timeSat Aug 23 23:51:20 2003
 /export/data magic   19540119 (UFS2) timeTue Aug 26 07:48:01 2003

What's magic?  Make it go away; the word usually means it's
so complicated, I can't explain it to you, and I implemented
the thing, so you should have szero faith in it, because if the
person who implemented it can't explain it, then it's going to
be impossible to verify correct operation.

-- Terry
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: nfs tranfers hang in state getblck or nfsread

2003-08-28 Thread Terry Lambert
Jason Stone wrote:
 I'm also seeing a similar problem - I have a cluster of high-volume
 mailservers delivering mail over nfs to maildirs on a netapp.  The cluster
 was all 4-stable, but I decided to mix a couple of 5.1 boxes in to see how
 they would do.
 
 The 5.1 boxes accepted and queued mail as well as the 4-stable boxes, but
 delivering the mail into the maildirs over nfs, I kept seeing those
 short-lived hangs, and so the queues started to back up as the boxes were
 accepting mail faster than they could deliver it.
 
 My mounts are all nfsv3 over udp.

UDP has problems, if you lose any packets at all.  The problem is
that the packet reassembly buffer stays full until you retry, and
the retry is out of band, for packets larger than the MTU size.

What happens when you drop the read and write size low enough that
the data and headers fit in a single UDP packet (e.g. according to
tcpdump)?  Does it suddenly become more reliable?

-- Terry
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: nfs tranfers hang in state getblck or nfsread

2003-08-28 Thread Robert Watson

On Wed, 27 Aug 2003, Pawel Worach wrote:

 I get the errors every time the nfs mounts are not unmounted cleanly,
 if the client (which is a laptop and i often forget to plug in the power
 so the battery dies) dies and the server is rebooted the client boots
 fine, i.e. no nfs server not responding errors. So it looks like there
 is some kind of state mismatch in the nfs server code. 

Ok, so let me see if I have the sequence of events straight:

(1) Boot a 4.8-RELEASE/STABLE NFS server
(2) Boot a 5.1-RELEASE/CURRENT NFS client
(3) Mount a file system using TCP NFSv3
(4) Reboot the client system, reboot, and remount
(5) Thrash the file system a bit with large reads/writes, and it hangs

Is this correct?  I'd like to work out the minimum sequence of events
necessary to cause the problem.  Is (4) necessary to reproduce the hang,
or can you cause it without (4) if you wait long enough?  You mention a
server reboot here, also, so I want to make sure I'm not confused about
the steps to hit the problem.

Also, could you try enabling the all.log entry in syslogd, and looking for
messages that read something like nfs send error in it after this has
happened?

Once the hang is occuring on the client, can you drop into DDB and do a
ps, and in particular, paste into an e-mail any lines about nfsiod
threads, and any threads that are blocked in nfs?

Likewise, on the server, could you drop into DDB and do a ps, and paste in
the state of any nfsd threads?

 rc.conf parameters look like this:  server: rpcbind_enable=YES
 nfs_server_enable=YES mountd_enable=YES 
 nfs_reserved_port_only=YES rpc_lockd_enable=YES
 rpc_statd_enable=YES  client: rpcbind_enable=YES
 nfs_client_enable=YES  rpc_lockd_enable=YES rpc_statd_enable=YES 

For kicks, try disabling rpc.lockd on all sides, as well as rpc.statd.  I
don't think they're involved here, but it's worth disabling them to be
sure.

Thanks,

Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
[EMAIL PROTECTED]  Network Associates Laboratories


___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: nfs tranfers hang in state getblck or nfsread

2003-08-28 Thread Jason Stone
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


  I'm also seeing a similar problem - I have a cluster of high-volume
  mailservers delivering mail over nfs to maildirs on a netapp.  The cluster
  was all 4-stable, but I decided to mix a couple of 5.1 boxes in to see how
  they would do.
[...]
  My mounts are all nfsv3 over udp.

 UDP has problems, if you lose any packets at all.  The problem is that
 the packet reassembly buffer stays full until you retry, and the retry
 is out of band, for packets larger than the MTU size.

 What happens when you drop the read and write size low enough that the
 data and headers fit in a single UDP packet (e.g. according to
 tcpdump)?  Does it suddenly become more reliable?

I'll try to play around with it and see.

We actually had this discussion already over on -performance (and I get
what you're saying), but the interesting question here is, why is 5.1
behaving so differently from 4-stable on identical hardware under
identical load.


 -Jason

 --
 Freud himself was a bit of a cold fish, and one cannot avoid the suspicion
 that he was insufficiently fondled when he was an infant.
-- Ashley Montagu
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.1 (FreeBSD)
Comment: See https://private.idealab.com/public/jason/jason.gpg

iD8DBQE/TfwcswXMWWtptckRAoZIAKCA6doHe3VXrwFj/xX/HkfV18emYACfW1GK
Yw5ZniWoHqHQg/ez8sj4Svc=
=hFfm
-END PGP SIGNATURE-
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: nfs tranfers hang in state getblck or nfsread

2003-08-28 Thread Robert Watson

On Thu, 28 Aug 2003, Terry Lambert wrote:

 Pawel Worach wrote:
 [ ... subject ... ]
 
  This only seem to happen for nfs over tcp.
 
 That's strange; most of the problems I've ever seen are from using UDP,
 large read/write sizes, and then droping one packet out of a bunch of
 frags caused by the MTU being much smaller than the read/write size
 (misguided attempt to emulate a fixed window size and get more packets
 in flight, without using TCP to do it). 

I'm wondering if large block sizes are causing the TCP socket buffer to
fill, resulting in some bad behavior on the client or server.  Most
probably the server, given that the scenarios in question seem to involve
reading.  Another intereseting test case might be to use dd with various
block sizes to read from a file on the server and see whether a particular
size triggers the problem, or if it's less deterministic (and more likely
a race condition of some sort).

Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
[EMAIL PROTECTED]  Network Associates Laboratories


___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: nfs tranfers hang in state getblck or nfsread

2003-08-28 Thread Pawel Worach
Robert Watson wrote:
On Wed, 27 Aug 2003, Pawel Worach wrote:

Ok, so let me see if I have the sequence of events straight:

(1) Boot a 4.8-RELEASE/STABLE NFS server
(2) Boot a 5.1-RELEASE/CURRENT NFS client
(3) Mount a file system using TCP NFSv3
(4) Reboot the client system, reboot, and remount
(5) Thrash the file system a bit with large reads/writes, and it hangs
Not quite, more like this:
1) Boot the 5.1-CURRENT nfs server
2) Boot the 5.1-CURRENT diskless client (i'm using PXE/DHCP)
3) Login and run find(1) for a while on every filesystem.
(e.g. find / ^C ; find /usr ^C ; find /export ^C and so on to
generate some getattr(), read() and c/o calls)
4) Shut down the client in a _non-clean_ way, pull the power
or enter DDB and 'reset'.
5) Boot the diskless client again.
Now here are the messages i get while booting the client (step 5).
(darkstar is the server, corona is the client. the one about mounttab
is present at every boot and is not related to this problem)
Mounting root from nfs:
NFS ROOT: 192.168.1.11:/export/root
start_init: trying /sbin/init
Interface fxp0 IP-Address 192.168.1.20 Broadcast 192.168.1.255
Loading configuration files.
Entropy harversting: interrupts ethernet point_to_point
Starting file system checks:
nfs: can't update /var/db/mounttab for darkstar:/export/root
+++ mount_md of /var
nfs server darkstar:/usr: not responding
insert about a 10 second delay here
nfs server darkstar:/usr: is alive again
nfs server darkstar:/usr/home: not responding
insert about a 20 second delay here
nfs server darkstar:/usr/home: is alive again
insert about a 20 second delay here
[tcp] darkstar:/export: nfsd: RPCPROG_NFS: RPC: Remote system error - Operation 
timed out
insert about a 80 second delay here
nfs server darkstar:/export: not responding
insert about a 40 second delay here
nfs server darkstar:/export: is alive again

From here on the boot continues normally and the system works fine.

I'm going to set different mount options for every filesystem now
and do this again so maybe i can nail down what is causing this.
Ths only filesystem that doesn't have problems is / and that is
also the only one using udp.
Hope this is not as confusing as my previus mail :)

And whoever commented about the magic stuff, that was a cut-and-paste from the
'dumpfs fs | grep UFS' command.
	- Pawel

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: nfs tranfers hang in state getblck or nfsread

2003-08-28 Thread Alexander Leidinger
On Thu, 28 Aug 2003 08:54:07 -0400 (EDT)
Robert Watson [EMAIL PROTECTED] wrote:

 Ok, so let me see if I have the sequence of events straight:
 
 (1) Boot a 4.8-RELEASE/STABLE NFS server
 (2) Boot a 5.1-RELEASE/CURRENT NFS client
 (3) Mount a file system using TCP NFSv3
 (4) Reboot the client system, reboot, and remount
 (5) Thrash the file system a bit with large reads/writes, and it hangs
 
 Is this correct?  I'd like to work out the minimum sequence of events
 necessary to cause the problem.  Is (4) necessary to reproduce the hang,
 or can you cause it without (4) if you wait long enough?  You mention a

As my server never shuts down and the 5-current client is switched off
in the night, I don't know about (4), but I don't think it's necessary
(on a shutdown the filesystems get umounted and /var/db/mountdtab only
show one mount for the client).

 server reboot here, also, so I want to make sure I'm not confused about
 the steps to hit the problem.

In my case there's no server reboot.

 Once the hang is occuring on the client, can you drop into DDB and do a
 ps, and in particular, paste into an e-mail any lines about nfsiod
 threads, and any threads that are blocked in nfs?

Normally I don't notice that it is blocked, as you see in the following,
it may also be the case, that the server is alive again in the same
second:
---snip---
/var/log/messages.0.bz2:Aug 24 11:52:05 Magelan kernel: nfs server 
Andro-Beta:/big/Windows: not responding
/var/log/messages.0.bz2:Aug 24 11:52:27 Magelan kernel: nfs server 
Andro-Beta:/big/Windows: is alive again
/var/log/messages.0.bz2:Aug 24 11:52:28 Magelan kernel: nfs server 
Andro-Beta:/big/Windows: not responding
/var/log/messages.0.bz2:Aug 24 11:52:36 Magelan kernel: nfs server 
Andro-Beta:/big/Windows: is alive again
/var/log/messages.0.bz2:Aug 24 11:52:46 Magelan kernel: nfs server 
Andro-Beta:/big/Windows: not responding
/var/log/messages.0.bz2:Aug 24 11:52:46 Magelan kernel: nfs server 
Andro-Beta:/big/Windows: not responding
/var/log/messages.0.bz2:Aug 24 11:52:46 Magelan kernel: nfs server 
Andro-Beta:/big/Windows: is alive again
/var/log/messages.0.bz2:Aug 24 11:52:46 Magelan kernel: nfs server 
Andro-Beta:/big/Windows: is alive again
/var/log/messages.0.bz2:Aug 24 11:53:13 Magelan kernel: nfs server 
Andro-Beta:/big/Windows: not responding
/var/log/messages.0.bz2:Aug 24 11:53:58 Magelan kernel: nfs server 
Andro-Beta:/big/Windows: is alive again
---snip---

 For kicks, try disabling rpc.lockd on all sides, as well as rpc.statd.  I
 don't think they're involved here, but it's worth disabling them to be
 sure.

There's no lockd running, only the statd on the server, so we already
can rule out the lockd.

BTW.: Robert, mwlucas CCed you in a mail regarding the use of the
FreeBSD Foundation address for the commercial icc license, can you
please confirm that you got the mail?

Bye,
Alexander.

-- 
   There's no place like ~

http://www.Leidinger.net   Alexander @ Leidinger.net
  GPG fingerprint = C518 BC70 E67F 143F BE91  3365 79E2 9C60 B006 3FE7
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: nfs tranfers hang in state getblck or nfsread

2003-08-28 Thread Andrew P. Lentvorski, Jr.
On Thu, 28 Aug 2003, Alexander Leidinger wrote:

 There's no lockd running, only the statd on the server, so we already
 can rule out the lockd.

You probably want to shut down statd on the server as well.  Since statd
is only used to recover locks on reboots, it is of no use without lockd,
and it can only get it the way.

-a

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: nfs tranfers hang in state getblck or nfsread

2003-08-28 Thread Pawel Worach
Pawel Worach wrote:
Robert Watson wrote:

On Wed, 27 Aug 2003, Pawel Worach wrote:

Ok, so let me see if I have the sequence of events straight:

Hope this is not as confusing as my previus mail :)

Here is some more information.
I realized that i had tcp and udp blackholing enabled on the server so i
disabled that, still no dice.
disabled rpc.statd and rpc.lockd, still no dice.
I escaped to DDB between the not responding and the ok messages
and came up with this:
[SLP]nfscon address] mount_nfs
[SLP]- address] nfsiod 3
[SLP]- address] nfsiod 2
[SLP]- address] nfsiod 1
[SLP]- address] nfsiod 0
I have also played with the mount options, here is the result of that:
ro,nfsv3,tcp,rdirplus - broken
ro,nfsv3,tcp - broken
ro,tcp - broken
ro - ok (defaults to nfsv2,udp according to my research)
ro,nfsv3 - ok (defaults to udp)
So it looks like what i said before, only tcp seems to cause this.

As this is the first time i'm seriusly investigating this i also noted
that a restart of the NFS daemons (or reboot) of the server is not needed,
just doing a _clean_ reboot (init 6, shutdown -r now) of the client will
make the server recover. (sometimes is takes two clean reboots).
	- Pawel

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: nfs tranfers hang in state getblck or nfsread

2003-08-27 Thread Pawel Worach
Alexander Leidinger wrote:

In this configuration I see a lot of nfs server ...: is not responding
and nfs server ...: is alive again when I copy large files (e.g. a CD
image). All of them happen in the same second. I haven't looked at the
state or priority of the cp process when this happens.
 

I have seen this too and i can reproduce it. I have a diskless client 
and if i unplug the power
and boot it up again i see the nfs server not responding messages for 
every filesystem being
mounted. Both client and server are of course FreeBSD-current, i have 
seen this for about
four mounts now.

   - Pawel

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: nfs tranfers hang in state getblck or nfsread

2003-08-27 Thread Robert Watson

On Wed, 27 Aug 2003, Pawel Worach wrote:

 In this configuration I see a lot of nfs server ...: is not responding
 and nfs server ...: is alive again when I copy large files (e.g. a CD
 image). All of them happen in the same second. I haven't looked at the
 state or priority of the cp process when this happens.
 
 I have seen this too and i can reproduce it. I have a diskless client
 and if i unplug the power and boot it up again i see the nfs server not
 responding messages for every filesystem being mounted. Both client and
 server are of course FreeBSD-current, i have seen this for about four
 mounts now. 

I have a very similar configuration, but it sounds like I'm not bumping
into the same problem.  Are you using NFSv2 or v3, and how many file
systems are you mounting?  Are you generally using UFS1 or UFS2?  Right
now, I'm mounting a single UFS2 file system was the root, and I believe
right now we always mount NFS roots at NFSv2, which could by why I'm not
seeing the same problem...

Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
[EMAIL PROTECTED]  Network Associates Laboratories

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: nfs tranfers hang in state getblck or nfsread

2003-08-27 Thread Pawel Worach
Robert Watson wrote:

I have a very similar configuration, but it sounds like I'm not bumping
into the same problem.  Are you using NFSv2 or v3, and how many file
systems are you mounting?  Are you generally using UFS1 or UFS2?  Right
now, I'm mounting a single UFS2 file system was the root, and I believe
right now we always mount NFS roots at NFSv2, which could by why I'm not
seeing the same problem...
Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
[EMAIL PROTECTED]  Network Associates Laboratories
 

Hi Robert!

This only seem to happen for nfs over tcp.

fstab on the client (/conf/default/etc/fstab) looks like:
server:/export/root   /   nfs ro  0   0
procfs  /proc   procfs  rw  0   0
server:/usr   /usrnfs ro,nfsv3,tcp0   0
server:/usr/home  /home   nfs rw,nfsv3,tcp0   0
server:/export/export nfs ro,nfsv3,tcp0   0
server:/export/data/swap  /swap   nfs rw,nfsv3,tcp0   0
/dev/acd0   /cdrom  cd9660  ro,noauto   0   0
/etc/exports on the server looks like:
/export -alldirs -maproot=root -network 192.168.1.0 -mask 255.255.255.0
/export/root -ro -maproot=0 client
/export/data/swap -mapall=nobody -network 192.168.1.0 -mask 255.255.255.0
/usr/home client
/usr -ro -network 192.168.1.0 -mask 255.255.255.0
filesystems on the server:
/magic   11954 (UFS1)timeWed Aug 27 17:34:13 2003
/usr magic   19540119 (UFS2) timeWed Aug 27 17:33:38 2003
/export magic   11954 (UFS1)timeSat Aug 23 23:51:20 2003
/export/data magic   19540119 (UFS2) timeTue Aug 26 07:48:01 2003
I get the errors every time the nfs mounts are not unmounted cleanly,
if the client (which is a laptop and i often forget to plug in the power
so the battery dies) dies and the server is rebooted the client boots fine,
i.e. no nfs server not responding errors. So it looks like there is some
kind of state mismatch in the nfs server code.
rc.conf parameters look like this:
server: rpcbind_enable=YES nfs_server_enable=YES mountd_enable=YES 
nfs_reserved_port_only=YES rpc_lockd_enable=YES rpc_statd_enable=YES
client: rpcbind_enable=YES nfs_client_enable=YES 
rpc_lockd_enable=YES rpc_statd_enable=YES

Regards
Pawel
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: nfs tranfers hang in state getblck or nfsread

2003-08-27 Thread Jason Dambrosio
On Wed, Aug 27, 2003 at 09:06:41AM -0400, Robert Watson wrote:
 I have a very similar configuration, but it sounds like I'm not bumping
 into the same problem.  Are you using NFSv2 or v3, and how many file
 systems are you mounting?  Are you generally using UFS1 or UFS2?  Right
 now, I'm mounting a single UFS2 file system was the root, and I believe
 right now we always mount NFS roots at NFSv2, which could by why I'm not
 seeing the same problem...

I had the same problem, replacing nfsv3 with tcp in my fstab fixed it.

4.8 server (ufs1), 5.0/5.1 clients, fstab looks like this now:

main:/data/home /data/home nfs rw,tcp,soft,intr,bg,rdirplus,noatime,nosuid,nodev
main:/data/config /data/config nfs rw,tcp,soft,intr,bg,rdirplus,noatime,nosuid,nodev
main:/data/www /data/www nfs rw,tcp,soft,intr,bg,rdirplus,noatime,nosuid,nodev

Jason
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: nfs tranfers hang in state getblck or nfsread

2003-08-25 Thread Bill Moran
Mike B wrote:
I'm running an nfs server from a freebsd 4.8 box and accessing in from a 
5.1 client machine. On small transfers I usually have no problems but 
when I run a high bandwidth task (normalizing audio tracks) the 
normalize process often gets stuck in the getblck state or nfsread 
state. The priority on this process is also set to -1.  Has anybody else 
experienced this problem? Thanks for the input.
I _may_ be seeing a similar problem, but I haven't analyzed it enough to
be sure yet.
If so, it's 5.1 client to 4.8 server as you describe.
I'll do a little testing and see if it seems to be the same as your
problem.
--
Bill Moran
Potential Technologies
http://www.potentialtech.com
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: nfs tranfers hang in state getblck or nfsread

2003-08-25 Thread Alexander Leidinger
On Sun, 24 Aug 2003 23:59:58 -0400
Bill Moran [EMAIL PROTECTED] wrote:

 Mike B wrote:
  I'm running an nfs server from a freebsd 4.8 box and accessing in from a 
  5.1 client machine. On small transfers I usually have no problems but 
  when I run a high bandwidth task (normalizing audio tracks) the 
  normalize process often gets stuck in the getblck state or nfsread 
  state. The priority on this process is also set to -1.  Has anybody else 
  experienced this problem? Thanks for the input.
 
 I _may_ be seeing a similar problem, but I haven't analyzed it enough to
 be sure yet.
 If so, it's 5.1 client to 4.8 server as you describe.

In this configuration I see a lot of nfs server ...: is not responding
and nfs server ...: is alive again when I copy large files (e.g. a CD
image). All of them happen in the same second. I haven't looked at the
state or priority of the cp process when this happens.

Bye,
Alexander.

-- 
The dark ages were caused by the Y1K problem.

http://www.Leidinger.net   Alexander @ Leidinger.net
  GPG fingerprint = C518 BC70 E67F 143F BE91  3365 79E2 9C60 B006 3FE7
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]