On Tue, Jan 30, 2018 at 12:31:22PM -0500, J. Bruce Fields wrote: > On Tue, Jan 30, 2018 at 04:49:41PM +0000, Terry Barnaby wrote: > > I have just tried running the untar on our work systems. These are again > > Fedora27 but newer hardware. > > I set one of the servers NFS exports to just rw (removed the async option in > > /etc/exports and ran exportfs -arv). > > Remounted this NFS file system on a Fedora27 client and re-ran the test. I > > have only waited 10mins but the overal network data rate is in the order of > > 0.1 MBytes/sec so it looks like it will be a multiple hour job as at home. > > So I have two completely separate systems with the same performance over > > NFS. > > With your NFS "sync" test are you sure you set the "sync" mode on the server > > and re-exported the file systems ? > > Not being a daredevil, I use "sync" by default: > > # exportfs -v /export <world>(rw,sync,wdelay,hide,no_subtree_check,sec=sys,insecure,no_root_squash,no_all_squash) > > For the "async" case I changed the options and actually rebooted, yes. > > The filesystem is: > > /dev/mapper/export-export on /export type ext4 (rw,relatime,seclabel,nodelalloc,stripe=32,data=journal) > > (I think data=journal is the only non-default, and I don't remember why > I chose that.) Hah, well, with data=ordered (the default) the same untar (with "sync" export) took 15m38s. So... that probably wasn't an accident. It may be irresponsible for me to guess given the state of my ignorance about ext4 journaling, but perhaps writing everything to the journal and delaying writing it out to its real location as long as possible allows some sort of tradeoff between bandwidth and seeks that helps with this sync-heavy workload. --b. _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
