FILE_SYNC slower than UNSTABLE + COMMIT

FILE_SYNC slower than UNSTABLE + COMMIT

[Venkatesh K S]

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  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: FILE_SYNC slower than UNSTABLE + COMMIT

[Chuck Lever]

On 13 Jan 2007 09:56:14 +0530, Venkatesh K S <vsharma@sonoasystems.com> wrote:
> 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

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.

-- 
"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  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs