Thank you Mikulas and Alasdair for your thoughts and ideas about alternatives. I'm aware of those alternatives. Android already uses DIO for loop devices for read performance for APEX mounts. Having an extra DM device was in fact our immediate fallback solution when I found this issue. Then, I thought that, if DM-device owned by another DM-device can be shared, why not share it with another read-only filesystem. > confuse dependencies in udev, What would it be like when a DM device is shared by two other DM devices like your suggestion #1 or #3? In #1 for example, a dm-verity device is shared by two dm-linear devices: one for /system filesystem mount and the other for APEX mount. I hope we can fix the issue around udev dependencies if there's any. > Will there be some performance degradation due to the extra linear device? > Could you measure it? I'll! There're two aspects: device creation and read performance. Both will affect syshealth. Fewer devices should definitely be a win. That's why I brought this to you ;-) If your patch can't make it, #1 is most likely the only option I have so I hope there's not much degradation. Thanks again. On Thu, Nov 14, 2024 at 2:25 AM Mikulas Patocka <mpatocka@xxxxxxxxxx> wrote: > > > > 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 >
