Hi Dave,
Just for completeness, XFS speculative preallocation (that is based now
upon the size of the last extent) can still grow up to 4Gb-8Gb (depending on
which patches we are pulling). As a result, xfs_iozero can still sometimes
trigger 1-2GB writes of zeros in one shot. This turns out to be a bit
unfriendly to the drives in some configurations. So we have applied a custom
patch to limit the speculative preallocation to 32Mb.
Final code will be in the same place.
Thanks,
Alex.
-----Original Message-----
From: Christoph Hellwig
Sent: 07 July, 2015 11:05 AM
To: Dave Chinner
Cc: Alex Lyakas ; Danny Shavit ; bfoster@xxxxxxxxxx ; Yair Hershko ; Shyam
Kaushik ; xfs@xxxxxxxxxxx
Subject: Re: xfs_iext_realloc_indirect and "XFS: possible memory allocation
deadlock"
On Tue, Jul 07, 2015 at 10:09:11AM +1000, Dave Chinner wrote:
server crash. i.e. the client side commit is an "fsync" to the
server, and until the server responds with a success to the client
commit RPC the client side will continue to retry sending the data
to the server.
For the persepctive of metadata (i.e. directory entries) the use of
the "dirsync" mount option is sufficient for HA failover servers to
work correctly as it ensures that directory structure changes are always
committed to disk before the RPC response is sent back to the
client.
i.e. the "sync" mount option doesn't actually improve data integrity
of an NFS server when you look at the end-to-end NFS protocol
handling of async write data....
You don't need dirsync either. NFS does the right sync usin the
commit_metadata export operation without using that big hammer.
_______________________________________________
xfs mailing list
xfs@xxxxxxxxxxx
http://oss.sgi.com/mailman/listinfo/xfs
