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
