On Tue, 12 Nov 2024, Jooyung Han wrote:
> Thanks Mikulas for the patch!
>
> This works like a charm. Here's how I tested: On Android, for an APEX
> file in /system partition, I create a dm-linear device with "shared"
> mode on top of the dm-verity device underlying the system partition.
> Previously, this failed with EBUSY because the dm-verity device is
> owned by the /system filesystem. But I was able to create it in a
> shared mode with your patch applied. Thanks again!
>
> Jooyung
Hi
I discussed this patch with Alasdair Kergon <a...@redhat.com> and he said
that it may confuse dependencies in udev, so the patch will likely not go
in.
But there are some alternatives:
1. create a linear device that maps the dm-verity device in 1:1
relationship. Then, mount the filesystem on this linear device. The
filesystem will claim only this linear device, so that you can create more
linear devices on the top of the dm-verity device.
Will there be some performance degradation due to the extra linear device?
Could you measure it?
2. use the loop device and enable direct I/O mode (use the ioctl
LOOP_SET_DIRECT_IO) - this should avoid double-caching and it should
increase the performance of the loop device. Does it improve performance?
3. use two dm-verity instances over one physical device - then, you can
mount the filesystem on one instance and create linear devices on the
other.
4. use the dm-loop target - https://www.sourceware.org/lvm2/wiki/DMLoop
https://patchwork.kernel.org/project/dm-devel/patch/1b84af841912065fc57cfe395d5214f4eee0f0fc.1516124587.git.hei...@redhat.com/
Some times ago we had a dm-loop target that queried the filesystem for a
layout of a file and then remapped the bios quickly according to this
layout tree. But now it's unmaintained and not updated to the latest
kernel. Perhaps it could be used for your purpose. I'm not sure what
filesystme maintainers will say about it.
Mikulas
