I think that the EJUKEBOX wrapper in fs/nfs/nfs3proc.c is not necessary
for nfs3_proc_read() and nfs3_proc_write().
Can you confirm this?
I want to simplify these particular cases while working on a redesigned
patchset for >16 groups support. Part of it are a number of cleanup
patches and they would be smaller when EJUKEBOX handling can be omitted
in these two functions.
--
Frank
-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
fr den 28.01.2005 Klokka 00:38 (+0100) skreiv Frank van Maarseveen:
> Because you have to open a file first. Well, as you said NFS is stateless
> so my guess is that the final lookup would return EJUKEBOX rather
> than any I/O on the file-handle. It seems unrealistic to me for a file to
> be archived _during_ I/O.
>
> Sure the protocol has the possibility to return EJUKEBOX in the middle
> of file I/O but does it make sense?
Of course it does. Files are only paged in from the storage medium on
demand in all modern OSes. That goes for ordinary disks, jukeboxed CDs,
tape,...
It is not as if the entire contents are read into memory when you call
open() on a disk-backed file either.
> BTW, I didn't see EJUKEBOX handling in NFSv4.
It is there, but you won't see it by just grepping the code for JUKEBOX:
in the NFSv4 protocol it has been renamed NFS4ERR_DELAY in order to
clarify its purpose. From RFC3530:
NFS4ERR_DELAY The server initiated the request, but was not
able to complete it in a timely fashion. The
client should wait and then try the request
with a new RPC transaction ID. For example,
this error should be returned from a server
that supports hierarchical storage and receives
a request to process a file that has been
migrated. In this case, the server should start
the immigration process and respond to client
with this error. This error may also occur
when a necessary delegation recall makes
processing a request in a timely fashion
impossible.
The Linux NFSv4 server may also return that error if it has to make an
upcall that for some reason takes longer than expected. For instance,
this may occur when translating a local uid or gid into the canonical
"name@domain" strings used by the NFSv4 GETATTR ops.
Note also that the NFSv4 (or Samba) "delegation recall" process is
something that will affect NFSv3 clients too if the same file is being
exported under NFSv4 (or Samba) and NFSv3. In that case it would be
appropriate for the NFSv3 server to send EJUKEBOX to the NFSv3 client
that has to wait.
Cheers,
Trond
--
Trond Myklebust <[email protected]>
-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
to den 27.01.2005 Klokka 23:59 (+0100) skreiv Frank van Maarseveen:
> I think that the EJUKEBOX wrapper in fs/nfs/nfs3proc.c is not necessary
> for nfs3_proc_read() and nfs3_proc_write().
>
> Can you confirm this?
Why do you believe that?
NFS is a stateless protocol: the server does not know when it is optimal
to cache a particular file, nor does it know exactly when it is optimal
to stop caching it (unless of course you delete it).
So sure, not only does the protocol allow the server to return EJUKEBOX
for both READ and WRITE requests, but it may also have a good reason to
do so (namely that it is no longer caching the file, and it has to read
it in from tape/cd/...).
Cheers,
Trond
--
Trond Myklebust <[email protected]>
-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
On Thu, Jan 27, 2005 at 03:19:57PM -0800, Trond Myklebust wrote:
> to den 27.01.2005 Klokka 23:59 (+0100) skreiv Frank van Maarseveen:
> > I think that the EJUKEBOX wrapper in fs/nfs/nfs3proc.c is not necessary
> > for nfs3_proc_read() and nfs3_proc_write().
> >
> > Can you confirm this?
>
> Why do you believe that?
Because you have to open a file first. Well, as you said NFS is stateless
so my guess is that the final lookup would return EJUKEBOX rather
than any I/O on the file-handle. It seems unrealistic to me for a file to
be archived _during_ I/O.
Sure the protocol has the possibility to return EJUKEBOX in the middle
of file I/O but does it make sense?
BTW, I didn't see EJUKEBOX handling in NFSv4.
--
Frank
-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
On Fri, Frank van Maarseveen wrote:
> On Thu, Jan 27, 2005 at 03:19:57PM -0800, Trond Myklebust wrote:
> > to den 27.01.2005 Klokka 23:59 (+0100) skreiv Frank van Maarseveen:
> > > I think that the EJUKEBOX wrapper in fs/nfs/nfs3proc.c is not necessary
> > > for nfs3_proc_read() and nfs3_proc_write().
> > >
> > > Can you confirm this?
> >
> > Why do you believe that?
>
> Because you have to open a file first. Well, as you said NFS is stateless
> so my guess is that the final lookup would return EJUKEBOX rather
> than any I/O on the file-handle. It seems unrealistic to me for a file to
> be archived _during_ I/O.
>
> Sure the protocol has the possibility to return EJUKEBOX in the middle
> of file I/O but does it make sense?
Yes. It makes sense. There are HSM solutions that keep the first
portion of the file on disk to be provided to things like the file
command. If the whole file is read, then subsequent READ requests
may receive EJUKEBOX.
>
> BTW, I didn't see EJUKEBOX handling in NFSv4.
NFS4ERR_DELAY
Spencer
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs