[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 <dholland-bugs%netbsd.org@localhost>
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:
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
(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
Main Index |
Thread Index |