[lkml]   [2005]   [Mar]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [NFS] [PATCH] SGI 926917: make knfsd interact cleanly with HSMs
On Thu, 2005-03-31 at 11:58, Neil Brown wrote:
> On Thursday March 31, 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...


> 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 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
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-04-06 13:31    [W:0.032 / U:9.508 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site