Re: rm(1) CPU hog

[David Holland <dholland-tech%netbsd.org@localhost>]

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 thought that patch had been committed...

 > 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.

Is there a way that partially-handled truncates get finished at
recovery time, or do files thus affected get left in an undefined
intermediate state?

-- 
David A. Holland
dholland%netbsd.org@localhost