Date: Mon, 20 Dec 2010 07:12:36 -0600 From: "James R. Van Artsdalen" <james-freebsd-fs2@jrv.org> To: Sergey Gavrilov <srg.gavrilov@gmail.com> Cc: freebsd-fs@freebsd.org, Ivan Voras <ivoras@freebsd.org> Subject: Re: ZFS recovery after power failure Message-ID: <4D0F5644.7060000@jrv.org> In-Reply-To: <AANLkTimo1WSR5wdS0Z24gGnt4-Utj1kdD__kCRUUxmTd@mail.gmail.com> References: <AANLkTikpYhLFxTp-5ahXQcZTMC5jMTK9Ca%2B6Xq4VEhhO@mail.gmail.com> <20101219123029.GM2127@garage.freebsd.pl> <AANLkTikW9gmeNcoc0XCV=BxMCmwjHfXh=sD4CdFJgzTs@mail.gmail.com> <iema5n$a99$1@dough.gmane.org> <4D0ED910.5010408@jrv.org> <AANLkTimo1WSR5wdS0Z24gGnt4-Utj1kdD__kCRUUxmTd@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 12/20/2010 12:59 AM, Sergey Gavrilov wrote: > Could you tell about why it can damage the pool in more details, please. Once the last uberblock write in a pool during a transaction group write has completed, ZFS may start reallocating and overwriting all blocks freed in the previous transaction group. Some of those blocks may contain necessary high-level pool data and metadata from the previous uberblock. If a power failure happens and an incorrectly-deferred uberblock update never happens, yet a write to a "free" block from above does commit to media, you can wind up with no uberblocks pointing to valid pool data. v28 "fixes" this by deferring reallocation of freed blocks for 3 transaction group updates. There is still a chance of failure but in the real world the odds of failure should be very low, although a disk controller with a big enough write-back cache might still run into a problem if it doesn't handle SYNC correctly.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4D0F5644.7060000>