On 2025/5/13 19:27, Sheng Yong wrote:
On 5/13/25 15:17, Gao Xiang wrote:
On 2025/5/13 15:06, Hongbo Li wrote:
On 2025/4/8 20:23, Sheng Yong wrote:
From: Sheng Yong <shengyo...@xiaomi.com>
When attempting to use an archive file, such as APEX on android,
as a file-backed mount source, it fails because EROFS image within
the archive file does not start at offset 0. As a result, a loop
device is still needed to attach the image file at an appropriate
offset first. Similarly, if an EROFS image within a block device
does not start at offset 0, it cannot be mounted directly either.
To address this issue, this patch adds a new mount option `fsoffset=x'
to accept a start offset for both file-backed and bdev-based mounts.
The offset should be aligned to block size. EROFS will add this offset
Hi Yong,
Why the offset should be aligned to block size? I mean, we can use
the original offset directly during read, and then add this offset
after reading.
Currently metabuf and bio are all block-based I/Os (otherwise
taking metadata for example, it could cross page boundary), I
Hi, Hongbo and Xiang,
I agree that "we cannot handle cross page/block" is the main reason. And
for use case, e.g APEX file, to achieve a better performance and make it
easy to extract filesystem image from a APEX file, the fs image is used
to put at page/block-size-aligned position.
ok, it may be complex, such as reading extra data with an aligned
position after plus fsoffset and redirecting the internal offset.
Should we consider adding the explanations in Documentation?
Thanks,
Hongbo
thanks,
shengyong
uess it's complex to support unaligned offsets. Also it seems
lack of use cases?
Thanks,
Gao Xiang
Thanks,
Hongbo
