Re: Journal question

On Mon, Dec 24, 2012 at 08:46:30PM +0200, Alex Pyrgiotis wrote:

Hi Kent,

I was reading the code documentation on your site, and I saw that
you have written this:

"... In the future, the journal will contain a strong checksum of
the data so that the write will complete when the journal entry
finishes..."

I think that was poorly worded. The idea is that if the pointer has a
data checksum, we can allow the journal entry to be written before all
the data it points to has been written, and then on recovery we can
figure out if we should replay keys in the journal entry by checking if
the checksums match (which means the data write did finish).

My question is, is this feature implemented?

Nah, would need to finish data checksumming first. I'm also not sure
it's really worth implementing, since awhile back I made it so only
cache flushes wait on journal writes... in the absence of cache flushes
we only write journal entries every ~100 ms by default.

Since cache flushes have to wait on outstanding data writes anyways it
wouldn't buy us much, it'd just let the data writes and journal write go
in parallel.

As far as I can see by
looking at journal.c, you are journaling only the keys and not the
data they point to (it has been issued asynchronously a few steps
back to the SSD, right?).

Yup, that's correct.

Also, if this is a feature to be implemented, wouldn't it create
more stress on the CPUs, as well as more latency to issue the IO
request to the SSDs (unless you issue it asynchronously while
processing the keylist)?

I'm just curious on how you'd handle it.

Not really, crc32c is ridiculously fast since it's implemented in
hardware and the 64 bit checksum bcache uses for some stuff is also
plenty fast. The checksumming overhead would only be noticable if we
were using something like sha1 (and there's advantages to using a crc
instead of a cryptographic hash - you can merge crcs (which we'd want to
do when merging extents), you can't merge cryptographic hashes).