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?= <e...@math.uni-bonn.de> > > 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 dholl...@netbsd.org