On 8/21/19 8:10 PM, Bill Maidment wrote:
> Hi
> During copying a large file (about 200GB) to a backup hard drive, I am 
> getting a multitude of XFS possible memory allocation deadlock messages.
> RedHat Portal shows the following:
> 
> XFS issues "possible memory allocation deadlock in kmem_alloc" messages
> Solution Verified - Updated August 9 2019 at 2:51 AM - English
> Issue
> 
>      Seeing file system access issues on XFS based file systems.
>      dmesg shows continuous entries with:
> 
>      XFS: possible memory allocation deadlock in kmem_alloc (mode:0x250)
> 
> Does anyone know what the solution is? And if SL7 will get this solution 
> soon?
> 

Here are the good bits from that page...
Also, you can create a free developer account and get access to these 
support topics and such resources.  There is a bit more info listed on 
the page, root cause, diagnostics, etc.

Resolution

This is a long standing issue with xfs and highly fragmented files.

kernel-3.10.0-1062.el7 from Errata RHSA-2019:2029 contains fixes to 
mitigate this issue when caused by individual file fragmentation. Please 
upgrade to this kernel or later.

Workarounds

There are several solutions that can be used to avoid high file 
fragmentation:

     Preallocate the space to be used by the file with unwritten 
extents. This gives the allocator the opportunity to allocate the whole 
file in one go and use the least amount of extents. As the blocks are 
written they will break up the unwritten extents into written/unwritten 
space and when all of the unwritten space has been converted the extent 
map will match the original optimal preallocated state.

     Use the extent size hint feature of XFS. This feature tells the 
allocator to allocate more space than may be needed by the current write 
request so that a minimum extent size is used. The extent will initially 
be allocated as an unwritten extent and will be converted as the 
individual blocks within the extent are written. As with preallocated 
files, when the entire extent has been written the extent size will 
match the original unwritten extent. The extent size hint feature can be 
set on a file or directory with this command:
     Raw

     $ xfs_io -c "extsize <extent size>" <dir or file>

     If set on a directory then all files created within that directory 
after the hint is set will inherit the feature. You cannot set the hint 
on files that already have extents allocated. If it is not possible to 
modify the application then this is the suggested option to use.

     Use asynchronous buffered I/O. This will offer the chance to have 
many logically consecutive pages build up in the cache before being 
written out. Extents can then be allocated for the entire range of 
outstanding pages instead of each page individually. This will not only 
reduce fragmentation but means less I/Os need to be issued to the 
storage device.

     Avoid writing the file in a random order. If blocks can be 
coalesced within the application before being written out using direct 
I/O then there's a chance the file can be written sequentially which the 
allocator can use to allocate extents contiguously.

     Use xfs_fsr to defragment individual large files. Note xfs_fsr is 
unable to defragment files that are currently in use, using the -v 
option is recommended to report on any issues that prevent defragmentation.
     Raw

     xfs_fsr -v /path/to/large/file