Journal question

Journal question

[Alex Pyrgiotis]

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..."

My question is, is this feature implemented? 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?).
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.

Thanks,
Alex

Re: Journal question

[Kent Overstreet]

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).