<div dir="ltr"><div dir="ltr">Hi Gao,</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Sep 21, 2024 at 1:02 AM Gao Xiang <<a href="mailto:hsiangkao@linux.alibaba.com">hsiangkao@linux.alibaba.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
Hi Fred,<br>
<br>
On 2024/9/21 00:11, Fred Lotter wrote:<br>
> Hi,<br>
> <br>
> In the context of this page:<br>
> <a href="https://erofs.docs.kernel.org/en/latest/merging.html" rel="noreferrer" target="_blank">https://erofs.docs.kernel.org/en/latest/merging.html</a> <<a href="https://erofs.docs.kernel.org/en/latest/merging.html" rel="noreferrer" target="_blank">https://erofs.docs.kernel.org/en/latest/merging.html</a>><br>
> <br>
> I am trying to experiment with EROFS where I want to try something crazy like the following setup:<br>
> <br>
> /dev/mmcblk0p3:<br>
> |<br>
> EROFS root image<br>
> |<br>
> --------<br>
> |<br>
> EROFS second image<br>
> |<br>
> --------<br>
> <br>
> I wanted to have a primate root EROFS filesystem written at the start of a partition. Then I would like to "append" files to the immutable root EROFS filesystem, by adding a concatenated EROFS filesystem after the root filesystem, with an external device reference pointing to the root EROFS filesystem.<br>
<br>
Thanks for your question.<br></blockquote><div><br></div><div>Thank you for your quick assistance. My final round of questions hopefully!</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> <br>
> My idea in my head was then to boot the Linux kernel with something like:<br>
> <br>
> root=/dev/mmcblk0p3 rootfstype=erofs rootoptions=device=/dev/mmcblk0p3,offset=<root size><br>
> <br>
> 1. Is it possible to have the "blobdevice" point to a complete EROFS filesystem?<br>
<br>
If there are two partitions, currently EROFS kernel runtime supports<br>
your requirement in practice, for example:<br>
<br>
  /dev/mmcblk0p3:<br>
  |<br>
  EROFS root image<br>
  |<br>
  -------- /dev/mmcblk0p4:<br>
  |<br>
  EROFS second image<br>
  |<br>
  --------<br>
<br>
You could boot with:<br>
root=/dev/mmcblk0p4 rootfstype=erofs rootoptions=device=/dev/mmcblk0p3<br>
<br>
to get the incremental filesystem and use:<br>
<br>
root=/dev/mmcblk0p3 rootfstype=erofs<br>
<br>
to boot the original filesystem.<br>
<br>
The two images are both usable for booting.<br></blockquote><div><br></div><div>This is still an interesting case for me, even if it has to be two explicit partitions.</div><div><br></div><div>In the case of the external device pointing to a complete EROFS filesystem.<br><br>Quoting from the documentation:<br>"There are no centralized inode and directory tables because they are not quite friendly for image incremental</div><div>updates, metadata flexibility, and extensibility. It’s up to users whether inodes or directories are arranged one</div><div>by one or not."<br><br>Does this mean with the current kernel implementation that the super erofs filesystem (containing a link to the</div><div>external erofs) can point to the original erofs filesystem, and only discover its contents at runtime? This would</div><div>allow me to mkfs.erofs a super erofs filesystem, without knowing anything about the external device content</div><div>at creation time?</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
The `offset` option is only supported by the loop device, and parsed by<br>
util-linux `mount` command, as in:<br>
<a href="https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/block/loop.c?h=v6.11#n52" rel="noreferrer" target="_blank">https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/block/loop.c?h=v6.11#n52</a><br>
<br>
So if you'd like to use the same partition, I guess it's still possible<br>
as long as you have a minimal initramfs to generate a special loop<br>
device with a specific offset, like:<br>
<br>
losetup -ooffset=<root size> /dev/loop0 /dev/mmcblk0p3<br>
mount -odevice=/dev/mmcblk0p3 /dev/loop0 /<br>
<br>
for example.  I'm not sure if it meets your requirement.<br>
<br>
In short, the on-disk format supports your requirement, and<br>
kernel runtime supports your requirement too, but just with<br>
two independent devices (or loop devices with `offset`).<br>
<br>
I'm not sure EROFS modules needs to support `offset`<br>
semantics since other filesystems don't support this too.<br>
<br>
> <br>
> 2. If yes, is there userspace support for creating this setup?<br>
<br>
Unfortunately, currently mkfs.erofs incremental build doesn't<br>
support this mode, but it can be implemented in the next<br>
erofs-utils 1.9 version.<br></blockquote><div><br></div><div>Is this a feature you plan to add in v1.9 in any case?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Thanks,<br>
Gao Xiang<br>
<br>
> <br>
> Kind Regards,<br>
> Fred<br>
></blockquote><div><br></div><div>I read some discussions on erofs verification:</div><div><a href="https://lore.kernel.org/lkml/Y69UjZP4dNYdbXW0@sol.localdomain/T/">https://lore.kernel.org/lkml/Y69UjZP4dNYdbXW0@sol.localdomain/T/</a><br></div><div><br></div><div>My impression is that dm-verity should work for EROFS filesystems today, in the same way it works with Squashfs.</div><div><br></div><div>However, I guess this would not work if the erofs super block device has a device table pointing to external block devices (erofs)?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <br>
> <br>
> <br>
> <br>
<br>
</blockquote></div></div>