On Mon, Apr 19, 2021 at 09:46:36AM +0000, Damien Le Moal wrote: > On 2021/04/19 18:41, h...@infradead.org wrote: > > On Mon, Apr 19, 2021 at 09:35:37AM +0000, Damien Le Moal wrote: > >> This is only to avoid someone from running zoned-btrfs on top of dm-crypt. > >> Without this patch, mount will be OK and file data writes will also > >> actually be > >> OK. But all reads will miserably fail... I would rather have this patch in > >> than > >> deal with the "bug reports" about btrfs failing to read files. No ? > >> > >> Note that like you, I dislike having to add such code. But it was my > >> oversight > >> when I worked on getting dm-crypt to work on zoned drives. Zone append was > >> overlooked at that time... My bad, really. > > > > dm-crypt needs to stop pretending it supports zoned devices if it > > doesn't. Note that dm-crypt could fairly trivially support zone append > > by doing the same kind of emulation that the sd driver does. > > I am not so sure about the "trivial" but yes, it is feasible. Let me think > about > something then. Whatever we do, performance with ZNS will no be great, for > sure... But for SMR HDDs, we likely will not notice any difference in > performance.
So this needs to be fixed outside of btrfs. The fix in btrfs would make sense in case we can't sync the dm-crypt and btrfs in a released kernel. Having a mount check sounds like a better option to me than to fail reads, we can revert it in a release once everything woks as expected.
