Re: rm(1) CPU hog

[Taylor R Campbell <campbell+netbsd-tech-kern%mumble.net@localhost>]

   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.