On Wed, 2019-01-30 at 11:00 -0500, Austin S. Hemmelgarn wrote: > 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. Does it? Isn't it then suffering from the same problems that any IO suffers (e.g. also from btrfs itself, with no further block layer beneath), when there are no barriers supported? > So, make sure your storage > devices support barriers properly first. Is there any proper way to do so? And if,... shouldn't the kernel then do this automatically? > > 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. Okay. But then the general official btrfs advise should probably be: [If the device supports barriers - and if not one is anyway at risk]... journaling at the lower dm-integrity level can be safely disabled, right? I would expect that there's no difference as to wheter nodatasum is used or not... cause even if one has a journal below which can be recovered, btrfs would not be able to make any use of this, or would it? If all this is truly the case (i.e. double checked by senior developers), then it should go into perhaps even both, btrfs and cryptsetup manpages. Cheers, Chris.
