ZFS vfs.zfs.cache_flush_disable and ZIL reliability

[Alexander Leidinger]

Quoting Jeremy Chadwick <freebsd at 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