NetBSD-Bugs archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

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

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

From: David Holland <>
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
 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

Home | Main Index | Thread Index | Old Index