[31] in The Cryptographic File System users list
Re: CFS problem with HPUX/NFS
daemon@ATHENA.MIT.EDU (Matt Blaze)
Thu Jan 1 21:48:34 1998
From owner-cfs-users@research.att.com Thu Jan 1 21:48:29 1998
Received: from rumor.research.att.com (rumor.research.att.com [192.20.225.9]) by bloom-picayune.MIT.EDU (8.7.6/2.3JIK) with SMTP id VAA01883 for <cfs-mtg@bloom-picayune.mit.edu>; Thu, 1 Jan 1998 21:48:27 -0500
Received: from research.att.com ([135.207.30.100]) by rumor; Thu Jan 1 21:45:09 EST 1998
Received: from amontillado.research.att.com ([135.207.24.32]) by research-clone; Thu Jan 1 21:46:49 EST 1998
Received: from nsa.research.att.com (majordomo@nsa.research.att.com [135.207.24.155])
by amontillado.research.att.com (8.8.7/8.8.7) with ESMTP id VAA11786;
Thu, 1 Jan 1998 21:46:41 -0500 (EST)
Received: (from majordomo@localhost) by nsa.research.att.com (8.7.3/8.7.3) id VAA26296 for cfs-users-list; Thu, 1 Jan 1998 21:46:26 -0500 (EST)
X-Authentication-Warning: nsa.research.att.com: majordomo set sender to owner-cfs-users@nsa.research.att.com using -f
Received: from amontillado.research.att.com (amontillado.research.att.com [135.207.24.32]) by nsa.research.att.com (8.7.3/8.7.3) with ESMTP id VAA26291 for <cfs-users@nsa.research.att.com>; Thu, 1 Jan 1998 21:46:23 -0500 (EST)
Received: from nsa.research.att.com (root@nsa.research.att.com [135.207.24.155])
by amontillado.research.att.com (8.8.7/8.8.7) with ESMTP id VAA11778;
Thu, 1 Jan 1998 21:46:20 -0500 (EST)
Received: from nsa.research.att.com (mab@localhost.research.att.com [127.0.0.1]) by nsa.research.att.com (8.7.3/8.7.3) with ESMTP id VAA26284; Thu, 1 Jan 1998 21:46:17 -0500 (EST)
Message-Id: <199801020246.VAA26284@nsa.research.att.com>
To: res@colnet.cmhnet.org (Rob Stampfli)
cc: cfs-users@research.att.com
Subject: Re: CFS problem with HPUX/NFS
In-reply-to: Your message of "Thu, 01 Jan 1998 19:45:00 EST."
<m0xnvEf-0008FOC@colnet.cmhnet.org>
Date: Thu, 01 Jan 1998 21:46:17 -0500
From: Matt Blaze <mab@research.att.com>
Sender: owner-cfs-users@research.att.com
Precedence: bulk
This sounds like a bug in the NFS client implementation -something may
be single-threaded that shouldn't be. I don't run HPUX, let alone have
source, so I can only guess what might be going on. It could also even
be a bug in the HPUX IP stack for large (fragmented) UDP packets sent to
the localhost interface. As a workaround, you might try reducing the NFS
block size on the mount command to something small, like 1024 or 2048.
Try adding rsize=2048,wsize=2048 or rsize=1024,wsize=1024 to the CFS mount
options and see if that fixes things.
By the way, you don't need to run CFS as your own userid, even when
attaching NFS-mounted files. It tries to do all file I/O under the uid
of the requester.
-matt
>Nothing seen for a while on this list, so let me ask about a CFS problem
>I recently encountered which I suspect is not really a CFS problem at all.
>It involves CFS, though, so let me pose it here:
>
>With the slowdown in things going on at work over the holidays, I had some
>spare time and decided to put CFS on my HP workstation. The machine, an HP
>model 712/60, runs HPUX 10.10. I acquired, compiled, and installed the
>beta2 code. The compile went well and CFS installed and appeared to work
>fine locally. However, my workstation does not have a very big disk, so I
>wanted to utilize space on the server to store my encrypted files. The
>server's disks are NFS mounted on the workstation, meaning that a reference
>via /crypt must take a double-dip to be serviced -- the first occuring over
>localhost to cfsd, and the second over NFS to the mainframe. I operate CFS
>like this all the time with Suns and have never had any problems with it.
>(I did know enough not to try running cfsd as a root process in this config-
>uration, as the remote NFS doesn't normally allow root much in the way of
>permissions on an NFS-mounted file system. Instead, I invoked cfsd as
>myself, as I don't want or expect anyone else to be using it.)
>
>Basically, it also seems to work fine for simple things. However, when I
>tried copying a large file (larger than about 10K) to the encrypted file
>system all NFS on the workstation locked up. Experimenting, I traced this
>down to a hung biod process (biods are the local daemons which handle the
>protocol for remote NFS mounts). If I started killing them until I found
>the hung one, NFS would spring back to life. However, the system would
>hang again the next time I tried accessing a large encrypted file. Small
>files, like "echo hi >hi", appear to reliably work just fine.
>
>In a word, I suspect this is a problem with NFS on the workstation, perhaps
>one that CFS is stimulating, but probably not responsible for. I have
>never had any problem with NFS on this machine with anything else, though.
>
>Any ideas? Has anyone done this successfully on an HP? Is there an HPUX
>patch I should apply? Its not really essential I get this working, but I'd
>like to understand what is going on.
>
>Thanks in advance for any ideas,
>--
>Rob Stampfli rob@colnet.cmhnet.org The Bill of Rights: It was a
>614-864-9377 HAM RADIO: kd8wk@w8cqk.oh good thing while it lasted...
