Date: Fri, 1 Apr 2011 20:09:31 +0200 From: Christian Walther <cptsalek@gmail.com> To: Adam Vande More <amvandemore@gmail.com> Cc: mlerota@claresco.hr, freebsd-stable@freebsd.org, Chris H <chris#@1command.com> Subject: Re: Constant rebooting after power loss Message-ID: <BANLkTim6WOYs9edQG_kmv3dU9khr6VtTEQ@mail.gmail.com> In-Reply-To: <AANLkTi=KEwmm1hM6Z=r_SWUAn9KhUrkTVzfF6VmqQauW@mail.gmail.com> References: <87d3l6p5xv.fsf@cosmos.claresco.hr> <AANLkTi=kEyz-mKLzdV8LAf91ZhMTP8gLKs=3Eu5WD8mh@mail.gmail.com> <874o6ip0ak.fsf@cosmos.claresco.hr> <7b15d37d28f8ddac9eb81e4390231c96.HRCIM@webmail.1command.com> <AANLkTi=KEwmm1hM6Z=r_SWUAn9KhUrkTVzfF6VmqQauW@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 1 April 2011 19:38, Adam Vande More <amvandemore@gmail.com> wrote: > On Fri, Apr 1, 2011 at 12:02 PM, Chris H <chris#@1command.com> wrote: > >> On Fri, April 1, 2011 6:29 am, Marko Lerota wrote: >> > =A0I read that ZFS don't need fsck because the files are always consis= tent >> on >> filesystem regardless >> > of power loses. That the corruption can occur only if disks are damage= d. >> But not >> > when power goes down. >> >> Complete nonsense. The information you read was false. >> > > =A0No, it's really not. =A0ZFS's lack of recovery tools at least in the > beginning were basically non existent. =A0 This is because ZFS uses a COW > model with an atomic data management unit design which by it's nature > addresses thing like fsck, and sudden power loss. Indeed. By copy on write and its' b-tree ZFS ensures consistency, however, this does not mean that there's no data loss. Writes are done in a transaction group, including an updated version of the b-tree. Only if all the new information has been written successfully the new b-tree "is tagged as valid" and becomes active. (Which is the reason why you can't rm files in a full pool.) If there's a power failure during a write ZFS recovers automatically during the mount (or zpool import, not sure on this one) _by deleting the inconsistent data_ and thus reverting to the last known state. Additionally, a transaction group may consist of several writes that reach a total size (I think 128Kb per default). If there are small and slow writes (e.g.to a Logfie) these are cached up to 30 seconds. If a power failure or any other kind of discruptive failure happens you'll loose all the information cached.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?BANLkTim6WOYs9edQG_kmv3dU9khr6VtTEQ>