From owner-freebsd-fs Sat Aug 21 18:11:27 1999 Delivered-To: freebsd-fs@freebsd.org Received: from dt011n65.san.rr.com (dt010nb9.san.rr.com [204.210.12.185]) by hub.freebsd.org (Postfix) with ESMTP id 4E493154B2 for ; Sat, 21 Aug 1999 18:11:09 -0700 (PDT) (envelope-from Doug@gorean.org) Received: from gorean.org (master [10.0.0.2]) by dt011n65.san.rr.com (8.9.3/8.8.8) with ESMTP id SAA97209; Sat, 21 Aug 1999 18:09:22 -0700 (PDT) (envelope-from Doug@gorean.org) Message-ID: <37BF4DCB.1E9B7F82@gorean.org> Date: Sat, 21 Aug 1999 18:09:31 -0700 From: Doug Organization: Triborough Bridge & Tunnel Authority X-Mailer: Mozilla 4.61 [en] (X11; U; FreeBSD 4.0-CURRENT-0815 i386) X-Accept-Language: en MIME-Version: 1.0 To: alk@pobox.com Cc: freebsd-fs@FreeBSD.ORG Subject: Re: blocking References: <14250.853.418320.65158@avalon.east> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Anthony Kimball wrote: > > An NFS blocking behaviour which doesn't seem correct to me: > > 1. background a long /bin/cp to /foo from an NFS-mounted file system. > 2. ls /foo > > note that (2) hangs until (1) completes. Is this a bug? Someone smarter than me will probably respond to tell me that I'm wrong, but in my nascent understanding of NFS I'd say no, although I can't quite explain exactly what I'm thinking about it. The best way I can express it is to say that while one client is already making a change on a file system more requests from the same client get queued. I believe that if you were to do the 'ls' from a different system it would not block. Ok, there's the slow hanging curve, someone else can step up and hit it out of the park. :) Doug To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message