On Thu, 2005-03-31 at 11:58, Neil Brown wrote: > On Thursday March 31, [EMAIL PROTECTED] 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
