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?
Obviously I need a better system for keeping track of open
issues... maybe some yellow postit notes would help :-)
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.
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" ...
Is this new semantic in any way 'standard' or accepted by the
filesystem gurus (e.g. Al Viro)??
NeilBrown
-------------------------------------------------------
This SF.net email is sponsored by Demarc:
A global provider of Threat Management Solutions.
Download our HomeAdmin security software for free today!
http://www.demarc.com/Info/Sentarus/hamr30
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
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.