Write cache, is write cache, is write cache?

[Šimun Mikecin]

2011/1/24 Šimun Mikecin <numisemis at gmail.com>

> 2011/1/24 Jeremy Chadwick <freebsd at jdc.parodius.com>
>
>> The term "flush" means many different things.  fsync(2), for example,
>> behaves differently on UFS than it does on ZFS.  People think that
>> "flush" means "guarantee the data written was written to disk", but
>> ensuring an actual ATA/SCSI command completes **and** has had its data
>> written to the platters is an entirely different beast (IMO) than "flush
>> kernel buffers to disk and hope for the best".
>>
>
> AFAIK, BIO_FLUSH should complete when data was written to disk (not
> before), or in the case of battery backed cache: when data was written to
> battery backed cache.
> AFAIK, ZFS doesn't only "flush kernel buffers" (like UFS does), but also
> executes BIO_FLUSH every X seconds (X=5 if my memory serves me well). So,
> you shouldn't loose data that was written before BIO_FLUSH executed.
>
>    With single disks, all I've seen are read/write errors which can't be
>
>> repaired.  "zpool status" will actually show what files got affected as
>> a result of the issue, though sometimes "zpool scrub" needs to be run
>> before this can be detected.
>
>
> Adding redudancy does make your data safer, but if everything is working as
> explained, sudden power-loss shouldn't be the cause of those errors even
> with single disks. Correct me if you think that I'm mistaken.
>

Well, when I think more about it, those errors might be from writing to disk
after last call to BIO_FLUSH. So you loose last 5 seconds at most. Not
something worth writing home about considering the performance advantage you
get by enabling write cache.