Slow concurrent reads on mounted loopback images

Slow concurrent reads on mounted loopback images

[GRANGER Nicolas]

[-- Attachment #1: Type: text/plain, Size: 555 bytes --]

Hi erofs team,


I'm working on a small daemon that caches and mounts disk images containing datasets based on usage (https://github.com/CEA-LIST/scratch_manager).

My understanding is that this is a good use-case for EROFS. However, in my experience concurrent reads on loopback mounted disk images are rather slow.

I tested both squashfs and erofs images so I don't think it is specific to erofs, I just can't figure out where the bottleneck is. By any chance would you have any any tips to share on that subject?


Best,

Nicolas Granger

[-- Attachment #2: Type: text/html, Size: 1076 bytes --]

Re: Slow concurrent reads on mounted loopback images

[Gao Xiang]

Hi GRANGER,

On 2024/3/22 01:49, GRANGER Nicolas wrote:
> Hi erofs team,
> 
> 
> I'm working on a small daemon that caches and mounts disk images containing datasets based on usage (https://github.com/CEA-LIST/scratch_manager <https://github.com/CEA-LIST/scratch_manager>).
> 
> My understanding is that this is a good use-case for EROFS. However, in my experience concurrent reads on loopback mounted disk images are rather slow.
> 
> I tested both squashfs and erofs images so I don't think it is specific to erofs, I just can't figure out where the bottleneck is. By any chance would you have any any tips to share on that subject?

Thanks for the information.  I don't know more about "scratch_manager",
but does "scratch_manager" really use loopback devices? if yes, which
kernel version are you using, and could you try with loop direct-io
mode?

Later the EROFS project will land native solutions for dataset and AI
models and we will evaluate this use cases formally.

Thanks,
Gao Xiang

> 
> 
> Best,
> 
> Nicolas Granger
>