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

[Hongbo Li]

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

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
>>
>>
>