On Wed, Jul 19, 2006 at 11:53:24AM +0100, Peter Grandi wrote:
> But write barriers are difficult to achieve, and when achieved they
> are often unreliable, except on enterprise level hardware, because
> many disks/host adapters/... simply lie as to whether they have
> actually started writing (never mind finished writing, or written
> correctly) stuff.
IDE/SATA doesn't have barrier to lie about (the kernel has to flush
and wait in those cases).
> The metadata will be consistent, but metadata and data may well will
> be lost. So the filesystem is still ''corrupted'', at least from the
> point of view of a sysadm who just wants the filesystem to be
> effortlessly foolproof.
Sanely written applications shouldn't lose data.
> Look at it from the point of view of a ''practitioner'' sysadm:
> ''who cares if the metadata is consistent, if my 3TiB
> application database is unusable (and I don't do backups
any sane database should be safe, it will fsync or similar as needed
this is also true for sane MTAs
i've actually tested sitations where transactions were in flight and
i've dropped power on a rack of disks and verified that when it came
up all transactions that we claimed to have completed really did
i've also done lesser things will SATA disks and email and it usually
turns out to also be reliable for the most part