FILE_SYNC slower than UNSTABLE + COMMIT
Subsystems (2)
Hi,
I have 2 different kernel versions and I notice that the way the nfs client honors O_SYNC is different.
In 2.6.12 variant the client issues UNSTABLE followed by a COMMIT call.
In 2.6.16 variant the nfs client issues a FILE_SYNC call.
The FILE_SYNC call turns out to be about 3 times slower against our server. Infact a simple write followed by a fsync also turns out to be FILE_SYNC calls. The mount is not a "sync" mount.
Is there a way a to make these calls in 2.6.16 or later release UNSTABLE + COMMIT ?
Are FILE_SYNC calls always slower (I wud assume for NVRAM based server it may be as fast as UNSTABLE). In which case this fix into a newer kernel seems to be biased towards working well with such servers
regards,
-venkatesh
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
Quoted 12 lines · Venkatesh K S
I have 2 different kernel versions and I notice that the way the nfs client honors
O_SYNCis different.
In 2.6.12 variant the client issues UNSTABLE followed by a COMMIT call.
In 2.6.16 variant the nfs client issues aFILE_SYNCcall.The
FILE_SYNCcall turns out to be about 3 times slower against our server. Infact a simple write followed by a fsync also turns out to beFILE_SYNCcalls. The mount is not a "sync" mount.
Quoted 6 lines
Is there a way a to make these calls in 2.6.16 or later release UNSTABLE + COMMIT ?
Are
FILE_SYNCcalls always slower (I wud assume for NVRAM based server it may be as fast as UNSTABLE). In which case this fix into a newer kernel seems to be biased towards working well with such servers
There are several reasons why using a FILE_SYNC write is preferable. You might find some discussion of this in the NFS mailing list archives.
1. Fewer operations on the wire. When the network latency is long, this is a preferrable optimization. I recall discussing handling only small (ie less than 2*wsize) writes this way; you should check how large O_SYNC writes are handled these days.
2. The client logic is simpler and less CPU intensive. Clients really can't guess which write model that a server might prefer, so they should optimize for their own advantage, not the server's.
3. Most servers use a write delay tactic to make FILE_SYNC writes more efficient (in terms of disk writes). This might make FILE_SYNC writes slower than UNSTABLE+COMMIT while retaining server disk subsystem scalability.
Signature · 11 lines
"We who cut mere stones must always be envisioning cathedrals" -- Quarry worker's creed ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ NFS maillist - [email protected] https://lists.sourceforge.net/lists/listinfo/nfs