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 <agk@xxxxxxxxxx> 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.heinzm@xxxxxxxxxx/ 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
