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.