EJUKEBOX and nfs3_proc_read()/nfs3_proc_write()
Subsystems (2)
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.
Signature · 11 lines
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
to den 27.01.2005 Klokka 23:59 (+0100) skreiv Frank van Maarseveen:
Quoted 4 lines
I think that the EJUKEBOX wrapper in
fs/nfs/nfs3proc.cis not necessary fornfs3_proc_read()andnfs3_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
Signature · 12 lines
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
Quoted 7 lines · Trond Myklebust
to den 27.01.2005 Klokka 23:59 (+0100) skreiv Frank van Maarseveen:
Quoted 4 lines
I think that the EJUKEBOX wrapper in
fs/nfs/nfs3proc.cis not necessary fornfs3_proc_read()andnfs3_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.
Signature · 11 lines
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:
Quoted 7 lines
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.
Quoted 1 line
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
Signature · 12 lines
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
Quoted 9 lines · Frank van Maarseveen
Quoted 7 lines · Trond Myklebust
to den 27.01.2005 Klokka 23:59 (+0100) skreiv Frank van Maarseveen:
Quoted 4 lines
I think that the EJUKEBOX wrapper in
fs/nfs/nfs3proc.cis not necessary fornfs3_proc_read()andnfs3_proc_write().Can you confirm this?
Why do you believe that?
Quoted 7 lines
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.
Quoted 2 lines
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