[PATCH v4 2/2] erofs: add 'fsoffset' mount option for file-backed & bdev-based mounts

[Sheng Yong]

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 <shengyong1 at 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.

thanks,
shengyong

> uess it's complex to support unaligned offsets.  Also it seems
> lack of use cases?
> 
> Thanks,
> Gao Xiang
> 
>>
>> Thanks,
>> Hongbo
> 
>