Benny Halevy wrote: > On Jun. 10, 2008, 21:52 +0300, Wendy Cheng <s.wendy.cheng@xxxxxxxxx> wrote: > >> 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 >> > > I'm not sure how the problem you referred to is related to the > one at hand. what I'm trying to say is that the sync _exports_ > flag has stronger affect on namespace modifying workloads, like > what I believe Frank's workload might be ... [snip] The referred thread showed "sync" export has performance impacts on Linux server *too*. -- 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
