xfs_iext_realloc_indirect and "XFS: possible memory allocation deadlock"

[Alex Lyakas]

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 at redhat.com ; Yair Hershko ; Shyam 
Kaushik ; xfs at oss.sgi.com
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.