Hello Dave, Brian, Christoph,
We are still encountering cases, in which different IO patterns beat XFS
preallocation schemes, resuling in highly fragmented files, having 100s of
thousands and sometimes millions of extents. In these cases XFS tries to
allocate large arrays of xfs_ext_irec_t structure with kmalloc, and this
often gets into numerous retries, and sometimes triggers hung task panic
(due to some other thread wanting to access the same file).
We made a change to call kmem_zalloc_large, which resorts to __vmalloc in
case kmalloc fails. kmem_free is already handling vmalloc addresses
correctly. The change is only for the allocation done in
xfs_iext_realloc_indirect, as this is the only place, in which we have seen
the issue.
Final code, as usual, will be in
https://github.com/zadarastorage/zadara-xfs-pushback
Thanks,
Alex.
-----Original Message-----
From: Dave Chinner
Sent: Friday, July 24, 2015 2:09 AM
To: Alex Lyakas
Cc: Christoph Hellwig ; Danny Shavit ; bfoster@xxxxxxxxxx ; Yair Hershko ;
Shyam Kaushik ; xfs@xxxxxxxxxxx
Subject: Re: xfs_iext_realloc_indirect and "XFS: possible memory allocation
deadlock"
On Thu, Jul 23, 2015 at 05:39:28PM +0200, Alex Lyakas wrote:
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.
It would be much better to change xfs_zero_eof() to convert extents
beyond EOF to unwritten extents rather than zero them. That way you
still get the benefits of the large speculative prealloc but without
the zeroing overhead that wierd sparse write patterns can trigger.
I just haven't got around to doing this because it hasn't been
reported as a significant problem for anyone until now.
Cheers,
Dave.
--
Dave Chinner
david@xxxxxxxxxxxxx
_______________________________________________
xfs mailing list
xfs@xxxxxxxxxxx
http://oss.sgi.com/mailman/listinfo/xfs
