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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
