>>>>> "fc" == Frank Cusack <fcus...@fcusack.com> writes:
fc> If you're misordering writes
fc> isn't that a completely different problem?
no. ignoring the flush cache command causes writes to be misordered.
fc> Even then, I don't see how it's worse than DROPPING a write.
fc> The data eventually gets to disk, and at that point in time,
fc> the disk is consistent. When dropping a write, the data never
fc> makes it to disk, ever.
If you drop the flush cache command and every write after the flush
cache command, yeah yeah it's bad, but in THAT case, the disk is still
always consistent because no writes have been misordered.
fc> In the face of a power loss, of course these result in the
fc> same problem,
no, it's completely different in a power loss, which is exactly the point.
If you pull the cord while the disk is inconsistent, you may lose the
entire pool. If the disk is never inconsistent because you've never
misordered writes, you will only lose recent write activity. Losing
everything you've ever written is usually much worse than losing what
you've written recently.
yeah yeah some devil's advocate will toss in, ``i *need* some
consistency promises or else it's better that the pool its hand and
say `broken, restore backup please' even if the hand-raising comes in
the form of losing the entire pool,'' well in that case neither one is
acceptable. But if your requirements are looser, then dropping a
flush cache command plus every write after the flush cache command is
much better than just ignoring the flush cache command. of course,
that is a weird kind of failure that never happens. I described it
just to make a point, to argue against this overly-simple idea ``every
write is precious. let's do them as soon as possible because there
could be Valuable Business Data inside the writes! we don't want to
lose anything Valuable!'' The part of SYNC CACHE that's causing
people to lose entire pools isn't the ``hurry up! write faster!''
part of the command, such that without it you still get your precious
writes, just a little slower. NO. It's the ``control the order of
writes'' part that's important for integrity on a single-device vdev.
pgpzrY74grvli.pgp
Description: PGP signature
_______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
