On Aug 11, 2009, at 7:15 PM, Jason Davies wrote:
On 12 Aug 2009, at 00:08, Robert Newson wrote:
The worst problem is that the disk controller will reorder sector
writes to reduce seek time, which in effect means that if power is
lost, some random subset of the last writes may not happen. So you
won't just end up with a truncated file
But what about that issue? It think it's tolerated because couchdb
searches backward for the last non-corrupt header, right?
find_header(_Fd, -1) ->
no_valid_header;
find_header(Fd, Block) ->
case (catch load_header(Fd, Block)) of
{ok, Bin} ->
{ok, Bin};
_Error ->
find_header(Fd, Block -1)
end.
What if the tail-header isn't corrupted but some of the preceding
writes were, due to the tail-header being written before preceding
blocks?
We fsync the everything to disk before we write the header, then fsync
again. It's possible to turn the fsyncs off via the ini if you know
that you FS won't reorder the writes.
-Damien
--
Jason Davies
www.jasondavies.com
