Date: Thu, 17 Mar 2011 09:37:15 +0100 From: Alexander Leidinger <Alexander@Leidinger.net> To: Jeremy Chadwick <freebsd@jdc.parodius.com> Cc: freebsd-fs@freebsd.org Subject: Re: ZFS vfs.zfs.cache_flush_disable and ZIL reliability Message-ID: <20110317093715.300351qg801prjgo@webmail.leidinger.net> In-Reply-To: <20110317074558.GA2248@icarus.home.lan> References: <20110317071618.GB49199@blazingdot.com> <20110317074558.GA2248@icarus.home.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
Quoting Jeremy Chadwick <freebsd@jdc.parodius.com> (from Thu, 17 Mar 2011 00:45:58 -0700): > Whenever this topic comes up, I always ask people the same 2 questions: > > > 1) What *absolute guarantee* do you have that data *actually gets > written to the platters* when BIO_FLUSH is called? You can > sync/sync/sync all you want -- there's no guarantee that the hard disk > itself (that is to say, the cache that lives on the hard disk) has fully > written all of its data to its platters. Obvious answer: None, if the disk lies to you. > 2) What do you think will happen when the hard disk abruptly loses > power? Could be the system PSU dying, could be the power circuitry on > the drive failing, could be a "quirk" that causes the drive to > power-cycle itself, etc... Obvious answer: You lose the data until the last sync (if the FS is DTRT like UFS+softupdates/journal or ZFS). > General question to users and/or developers: > > Can someone please explain to me why people are so horribly focused (I > would go as far to say OCD) on this topic? > > Won't there *always* be some degree of potential loss of data in the > above two circumstances? Shouldn't the concern be less about "how much > data just got lost" and more about "is the filesystem actually usable > and clean/correct?" (ZFS implements the latter two assuming you're > using mirror or raidz). You want to always have a consistent FS, that's sure. Parts of consistency guarantees depend upon having data on disk for sure before other changes. You do not want to have the data (FS meta-data) before a flush point reordered in the cache after data (FS meta-data) which was written after the flush point. You also want to lose as less data as possible: Think about your bank account while doing transactions. If the disk lies, it could be (attention, huge simplification here) that your transaction to someone was made but the bank "forgets" to remove the money from your account. This is surely something nobody of us would mind, but the bank does. The other way around, someone transfers money to you, it is removed from his account, but not added to your one, is a more unpleasant one you surely would object about. I'm sure you know about the "only acknowledge to the remote side if the data is really stored" way of handling transfers (mail, DB, ...). If the disk lies to you, you can not do anything (maybe you got what you payed for), but if you have disks which actually DTRT, you do not lose mail (sender retries) or money (the transaction processing can restart from the last ACKed point). Bye, Alexander. -- Even if you do learn to speak correct English, whom are you going to speak it to? -- Clarence Darrow http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110317093715.300351qg801prjgo>