Re: dm-integrity + mdadm + btrfs = no journal?

["Austin S. Hemmelgarn" <ahferroin7@gmail.com>]

On 2019-01-30 10:26, Christoph Anton Mitterer wrote:
> On Wed, 2019-01-30 at 07:58 -0500, Austin S. Hemmelgarn wrote:
>> Running dm-integrity without a journal is roughly equivalent to
>> using
>> the nobarrier mount option (the journal is used to provide the same
>> guarantees that barriers do).  IOW, don't do this unless you are
>> willing
>> to lose the whole volume.
> 
> That sounds a bit strange to me.
Probably because I forgot to qualify the statement properly and should 
have worded it differently.  It should read:

Running dm-integrity on a device which doesn't support barriers without 
a journal is risky, because the journal can help mitigate the issues 
arising from the lack of barrier support.  So, make sure your storage 
devices support barriers properly first.
> 
> My understanding was that the idea of being able to disable the journal
> of dm-integrity was just to avoid any double work, if equivalent
> guarantees are already given by higher levels.
Except they aren't completely if the storage device doesn't support 
barriers properly.
> 
> If btrfs is by itself already safe (by using barriers), then I'd have
> expected that not transaction is committed, unless it got through all
> lower layers... so either everything works well on the dm-integrity
> base (and thus no journal is needed)... or it fails there... but then
> btrfs would already safe by it's own means (barriers + CoW)?
BTRFS is _mostly_ safe.  The problem is that there are still devices out 
there that don't have proper barrier support.  Without barriers, the 
superblocks can hit the disk before the most recent transactions do, and 
in that case you're kind of screwed.  dm-integrity's journaling can help 
protect against this to a limited degree (it doesn't completely solve 
the issue, but it's better than nothing), but at the cost of higher 
overhead from duplicated work.