On 3/10/2011 1:50 PM, John R Pierce wrote:
>
> battery backed writeback caches on raid controllers flush any pending
> data to the disks when power is restored. if for some reason they
> can't, they flag an error
I know what they are supposed to do - I was just wondering if it happens
in practice under real-world conditions.
> when an application (such as database server) or file system issues a
> fdatasync or fsync, it expects that when that operation returns success,
> all data has been committed to non-volatile storage. BBWC exist to
> speed up that critical operation, as actualy committing data to disk is
> slow and expensive. This is of particular importance to a
> transactional database server, each COMMIT; has to be committed to disk.
But if you didn't just do the fsync (i.e. you are running just about
anything but a transactional db), odds are that the directory update
won't match the data and journal recovery will drop it anyway.
>
> I am intentionally sidestepping the issue of cheap desktop grade storage
> that ignores buffer flush commands as these really aren't suitable for
> transactional database servers unless your data just isn't that
> important. IDE and SATA stuff has always been 'soft' on this, while
> SCSI, FC, and SAS drives are much more consistent.
I thought there were also problems in layers like lvm that keep the OS
from knowing exactly what happened. And a lot of software that should
fsync at certain points probably doesn't because linux has historically
handled it badly.
--
Les Mikesell
lesmikesell at gmail.com