From mboxrd@z Thu Jan 1 00:00:00 1970 From: Greg Banks Subject: Re: O_NONBLOCK for regular files Date: Sat, 20 Mar 2004 20:24:16 +1100 Sender: linux-fsdevel-owner@vger.kernel.org Message-ID: <405C0DC0.3E61994@melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Return-path: Received: from mtvcafw.SGI.COM ([192.48.171.6]:58244 "EHLO omx2.sgi.com") by vger.kernel.org with ESMTP id S263262AbUCTJYT (ORCPT ); Sat, 20 Mar 2004 04:24:19 -0500 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with SMTP id i2KBQd4M031554 for <@external-mail-relay.sgi.com:linux-fsdevel@vger.kernel.org>; Sat, 20 Mar 2004 03:26:40 -0800 Received: from melbourne.sgi.com (speed.melbourne.sgi.com [134.14.55.174]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id UAA00759 for ; Sat, 20 Mar 2004 20:24:16 +1100 To: Linux Filesystem Development List List-Id: linux-fsdevel.vger.kernel.org Jamie Lokier wrote: > Christoph Hellwig wrote: > > It's used to [...] return EAGAIN to the nfs server so it doesn't block all > > nfsd threads on possible long-enduring HSM operations. > > How does nfsd get notified when the operation is possible? It doesn't; the nfsd sends an RPC reply containing the NFSERR_JUKEBOX error to the NFS client, which sleeps and retries the operation after a few seconds. If the operation is not yet possible the cycle repeats. This is according to the RFC for NFSv3 and NFS clients (including Linux) know how to handle it. The point is to free the nfsd and corresponding client-side resources for other NFS traffic while HSM operation continues. Also, without this there's a pathological situation where the client keeps retrying, getting a new nfsd each time, until all the nfsds are blocked on the same file and all NFS traffic to the server stops. Greg. -- Greg Banks, R&D Software Engineer, SGI Australian Software Group. I don't speak for SGI.