Re: kern/47937: mount -o discard,log is broken

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

The following reply was made to PR kern/47937; it has been noted by GNATS.

From: David Holland <dholland-bugs%netbsd.org@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: 
Subject: Re: kern/47937: mount -o discard,log is broken
Date: Mon, 17 Jun 2013 00:33:30 +0000

 On Sun, Jun 16, 2013 at 11:20:01PM +0000, Jeff Rizzo wrote:
  >  With some help from riastradh@, this actually seems to make it work:
  >
  > [snip]
 
 It would probably be a good idea to make sure it doesn't break
 recovery. In WAPBL block freeing already goes through one layer of
 delayed action; it's quite possible that delaying things longer will
 violate assumptions made by the recovery logic.
 
 The case I'd be particularly worried about is if you delete a bunch of
 things, it goes to commit all the transactions and does so and then
 writes a snapshot; but the blocks haven't actually been freed yet so
 if you then crash and recover to that snapshot you'll leak all the
 blocks.
 
 But that's not the only one.
 
 It would be helpful to test it. Testing recovery is in general
 difficult, but for this it's probably sufficient to try these cases:
 
 (a) put an unconditional panic in the discard path before starting a
 wapbl transaction;
 
 (b) put "if (counter++ == 500) panic()" inside the wapbl transaction;
 
 and for both cases rm -r a sizeable tree (including at least some
 large files that have indirect blocks...). Then afterwards let the
 journal recovery run and then fsck.
 
 I'll be much more comfortable with this if it fscks clean reliably
 under such circumstances.
 
 Why does TRIM get run in the background like this at all, anyway? Are
 we concerned about it being slow?
 
 -- 
 David A. Holland
 dholland%netbsd.org@localhost