On Thu, 14 Nov 2024, Jooyung Han wrote: > 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. Hi Jooyung I revived the old dm-loop target (I'm sending it in the next email). It works as a regular loop driver, but it has better performance because it builds a map of the file in the constructor and then it just remaps bios. It doesn't bounce the bios through a workqueue like the existing loop driver. It'd like to ask you to test if the dm-loop driver fits your needs of mounting the APEX images. You can create a mapping of a file "/root/file" with this command: dmsetup create loop --table '0 524288 loop /root/file 0' The last number on the constructor line is the byte offset into the file where the mapping starts. Mikulas
