Messages in this thread | | | Subject | Re: [NFS] [PATCH] SGI 926917: make knfsd interact cleanly with HSMs | From | Greg Banks <> | Date | Thu, 31 Mar 2005 12:18:42 +1000 |
| |
On Thu, 2005-03-31 at 11:58, Neil Brown wrote: > On Thursday March 31, gnb@melbourne.sgi.com wrote: > > On Tue, 2005-03-15 at 18:49, Greg Banks wrote: > > > This patch seeks to remedy the interaction between knfsd and HSMs by > > > providing mechanisms to allow knfsd to tell an underlying filesystem > > > (which supports HSMs) not to block for reads, writes and truncates > > > of offline files. It's a port of a Linux 2.4 patch used in SGI's > > > ProPack distro for the last 12 months. The patch: > > > > Any news on this patch? Is it good, bad, ugly, or what? > [...] > Yes, it looks reasonably sane. > > I'm not very comfortable about the > > + if (rqstp->rq_vers == 3) > > usage. Shouldn't it be > + if (rqstp->rq_vers >= 3) > as presumably NFSv4 would like NFSERR_JUKEBOX returns too.
I guess so, but I haven't tested it with v4. I'll update the patch.
> Also, it assumes an extension to the semantics of IFREG files such > that O_NONBLOCK has a meaning...
Yes.
> What exactly is that meaning? > "Returned -EAGAIN if the request will take a long time for some vague > definition of long" ...
This is one of the issues I'd appreciate some real feedback on, so I've cc'ed lkml and fsdevel.
The specific and practical answer is "Return -EAGAIN if DMAPI decides it needs to queue an event", but that only applies to XFS (and JFS in SLES) so it's not really a generic definition.
>From knfsd's point of view, the desired definition is "Return -EAGAIN if the operation is likely to take longer than a client RPC timeout". Of course, the server doesn't know what that number is, although 1.1 sec is a pretty good guess.
Perhaps the best definition is "Return -EAGAIN if the operation needs to block on something other than a disk IO". This covers what actually happens in the guts of XFS, what needs generically to happen for HSMs, and suits the needs of knfsd.
> Is this new semantic in any way 'standard' or accepted by the > filesystem gurus (e.g. Al Viro)??
It's not currently standard; my hope is to extend the standard. I've cc'ed Al Viro in the hope of some feedback.
Greg. -- Greg Banks, R&D Software Engineer, SGI Australian Software Group. I don't speak for SGI.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |