Re: rm(1) CPU hog

[Thor Lancelot Simon <tls%panix.com@localhost>]

Welcome to XFS!  I wonder if they ever fixed this in XFS.

On Wed, Jul 01, 2015 at 06:38:54PM +0000, Taylor R Campbell wrote:
>    Date: Wed, 1 Jul 2015 15:19:53 +0200
>    From: Edgar =?iso-8859-1?B?RnXf?= <ef%math.uni-bonn.de@localhost>
> 
>    I just noticed a rm(1) of a 6.4G file (WAPBL 16k FFSv2) taking 35 seconds.
>    The astonishing fact was the undelying disc being idle (according to iostat) 
>    and rm being CPU-bound.
> 
> The problem is that to set a bound on the size of wapbl transactions,
> deleting an inode truncates it -- and commits the truncation to the
> journal -- one indirect block at a time, even if the file is sparse in
> which case most such truncations don't actually do anything.
> 
> There's a patch floating around to ascertain how much space is left in
> the current transaction and truncate as many blocks as will fit in it
> at a time.  I think a better approach would be to truncate only blocks
> that are actually allocated, and skip holes, but I haven't finished
> the patch to do that.

-- 
 Thor Lancelot Simon	                                      tls%panix.com@localhost
"From the tooth paste you use in the morning to the salt on your evening meal,
it's easy to take for granted the many products brought to us with explosives."
    - Institute of Manufacturers of Explosives, "Explosives Make It Possible"