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.
