Re: [NFS] Does "sync" cause the FUA bit to be set?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Benny Halevy wrote:
> On Jun. 10, 2008, 18:44 +0300, Wendy Cheng <s.wendy.cheng@xxxxxxxxx> wrote:
>   
>> Frank Steiner wrote:
>>     
>>> With the profile ignoring the FUA bit, copying or deleting directories
>>> of e.g. 10M with a about 1000 files is factor 5 faster than with the
>>> profile honoring the FUA bit.
>>>   
>>>       
>> FUA bit is normally combined with write-thru scsi command that bypasses 
>> storage write cache. I would imagine it needs to well synchronize 
>> various pieces before issuing this command. It could hurt the 
>> performance if not done well, particularly for meta data. So your result 
>> is not surprising.
>>     
>>> We export with the "sync" option. Does that option maybe set the FUA bit
>>> for all write operations on the NFS server?
>>>   
>>>       
>> It depends on how the filesystem (and its associated disk subsystem) is 
>> implemented. The "sync" export option itself has a heavy performance 
>> impact, regardless how FUA bit is handled. Some vendors uses specialized 
>> HW (e.g. NVRAM) to alleviate this performance hit. If your filesystem 
>> doesn't have this type of support, you should expect "sync" option runs 
>> much much slower than "async". It is a choice (or balance) between cost, 
>> performance, and data reliability.
>>     
>
> Wendy, I *think* what you have in mind is the sync mount option
> rather than the sync export flag.  The latter just tells the server
> not to cheat and do everything asynchronously.  It should *not*
> have a heavy performance penalty for I/O intensive writes if the
> client is using async writes and commits.
>
>   
No, I didn't get confused ... We can use Linux as an example :) .. check 
out:
http://marc.info/?l=linux-nfs&m=119618886105337&w=2

-- quote

The default export might have been "async", but unless the option "sync"
in /etc/exports was being ignored I was already using "sync". Nevertheless
I will try to change to async and test if it makes a difference.

(one day later: )

I have now tried it and the load on the NFS server is much lower and KDE
logins seem to be reasonably fast now.

-- un-quote


-- Wendy

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
NFS maillist  -  NFS@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/nfs
_______________________________________________
Please note that nfs@xxxxxxxxxxxxxxxxxxxxx is being discontinued.
Please subscribe to linux-nfs@xxxxxxxxxxxxxxx instead.
    http://vger.kernel.org/vger-lists.html#linux-nfs

--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Filesystem Development]     [Linux USB Development]     [Linux Media Development]     [Video for Linux]     [Linux NILFS]     [Linux Audio Users]     [Yosemite Info]     [Linux SCSI]

  Powered by Linux