On 2015-09-18 04:22, Duncan wrote:
one way or another, you're going to
have to write two things, one a checksum of the other, and if they are
in-
place-overwrites, while the race can be narrowed, there's always going
to
be a point at which either one or the other will have been written,
while
the other hasn't been, and if failure occurs at that point...
...then you still can recover the old data from the mirror or parity,
and at least you don't have any inconsistent data. It's like the failure
occurred just a tiny bit earlier.
The only real way around that is /some/ form of copy-on-write, such
that
both the change and its checksum can be written to a different location
than the old version, with a single, atomic write then updating a
pointer
to point to the new version of both the data and its checksum, instead
of
the old one.
Or an intent log, but I guess that introduces a lot of additional writes
(and seeks) that would impact performance noticeably...
Gert
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
