Hello all, I think the two options are very similar in the "cliente side view", but i want to hear from the experts... So, somebody can talk a little about the two options? We have two different layers here, i think: 1) The "async" from the protocol stack, and the other... 2) From the filesystem point of view. What makes me think that the "first" option could be more "quick" for the client, because the "ack" is in a higher level (NFS protocol). Please, comment! Leal. This message posted from opensolaris.org
On Apr 22, 2008, at 12:16 PM, msl wrote:> Hello all, > I think the two options are very similar in the "cliente side > view", but i want to hear from the experts... So, somebody can talk > a little about the two options? > We have two different layers here, i think: > 1) The "async" from the protocol stack, and the other... > 2) From the filesystem point of view. > > What makes me think that the "first" option could be more "quick" > for the client, because the "ack" is in a higher level (NFS protocol).The NFS client has control over WRITE requests in that it may ask to have them done "async" and then follow it with a COMMIT request to ensure the data is in stable-storage/disk. However, the NFS client has no control over namespace operations (file/directory create/remove/rename). These must be done synchronously -- no way for the client to direct the operational behavior of the server in these cases. Spencer
> > On Apr 22, 2008, at 12:16 PM, msl wrote: > > > Hello all, > > I think the two options are very similar in the > "cliente side > > view", but i want to hear from the experts... So, > somebody can talk > > a little about the two options? > > We have two different layers here, i think: > > 1) The "async" from the protocol stack, and the > other... > > 2) From the filesystem point of view. > > > > What makes me think that the "first" option could > be more "quick" > > for the client, because the "ack" is in a higher > level (NFS protocol). > > The NFS client has control over WRITE requests in > that it > may ask to have them done "async" and then follow it > with > a COMMIT request to ensure the data is in > stable-storage/disk.Great information... so, the "sync" option on the server (export) side is just a "possible" option for the client requests? I mean, the "sync/async" option is a requirement in a nfs write request operation? When i did the question, i was talking about the "server side", i did not know about the possibility of the client requests "sync/async".> > However, the NFS client has no control over namespace > operations > (file/directory create/remove/rename). These must be > done > synchronously -- no way for the client to direct the > operational > behavior of the server in these cases.If i understand well, here the "zil_disable" is is a problem for the NFS semantics... i mean, the service will be compromise, because the nfs client can''t control the "namespace operations". What is a big diff in my initial question.> > Spencer >Thanks a lot for your comments! Anybody else? ps.: how can i enable async in nfs server on solaris? just add "async" for the export options? Leal.> _______________________________________________ > nfs-discuss mailing list > nfs-discuss at opensolaris.orgThis message posted from opensolaris.org
On Apr 22, 2008, at 2:00 PM, msl wrote:>> >> On Apr 22, 2008, at 12:16 PM, msl wrote: >> >>> Hello all, >>> I think the two options are very similar in the >> "cliente side >>> view", but i want to hear from the experts... So, >> somebody can talk >>> a little about the two options? >>> We have two different layers here, i think: >>> 1) The "async" from the protocol stack, and the >> other... >>> 2) From the filesystem point of view. >>> >>> What makes me think that the "first" option could >> be more "quick" >>> for the client, because the "ack" is in a higher >> level (NFS protocol). >> >> The NFS client has control over WRITE requests in >> that it >> may ask to have them done "async" and then follow it >> with >> a COMMIT request to ensure the data is in >> stable-storage/disk. > Great information... so, the "sync" option on the server (export) > side is just a "possible" option for the client requests? I mean, > the "sync/async" option is a requirement in a nfs write request > operation? When i did the question, i was talking about the "server > side", i did not know about the possibility of the client requests > "sync/async".The Solaris NFS server does not offer a method to specify "sync/ async" behavior for NFS WRITE requests. The Solaris server will do what the client asks it to do.>> However, the NFS client has no control over namespace >> operations >> (file/directory create/remove/rename). These must be >> done >> synchronously -- no way for the client to direct the >> operational >> behavior of the server in these cases. > If i understand well, here the "zil_disable" is is a problem for > the NFS semantics... i mean, the service will be compromise, > because the nfs client can''t control the "namespace operations". > What is a big diff in my initial question.Yes, zil_disable can be a problem as described by Eric here: http://blogs.sun.com/erickustarz/entry/zil_disable>> >> Spencer >> > Thanks a lot for your comments! Anybody else? > ps.: how can i enable async in nfs server on solaris? just add > "async" for the export options?See above; not possible. Spencer