Thank you, I shall ask the os-prober maintainers instead, it sounds like
regular mount (or something else) would be better to use for that purpose after
perhaps testing it's available, I'd guess grub-mount might have been designed
to use in the minimal early boot environment with the limited resources
available at that point.
May 13, 2024, 21:59 by phco...@gmail.com:
> We don't maintain os-prober. As for grub-mount it was never meant to be fast
> and certainly isn't
>
> Le lun. 13 mai 2024, 22:47, stratus--- via Bug reports for the GRand Unified
> Bootloader <> bug-grub@gnu.org> > a écrit :
>
>> Dear Grub maintainers, myself and others on the Artix forum have experienced
>> problems with os-prober running very slowly. The issue seems to occur in
>> other distros as well, and the same subject has come up before in the past:
>> >> https://forum.artixlinux.org/index.php/topic,6818.msg41493
>> It appears that grub-mount uses a FUSE mount which requires a specific
>> implementation for different filesystems. When the partitions are mounted
>> with grub-mount, file reading operations are vastly slower than when mounted
>> by the normal mount command. This is even worse on BTRFS than with EXT4, and
>> it looks like NTFS is probably very slow too. This can be easily tested by
>> using grub-mount to mount a partition then seeing how long it takes to copy
>> some files over compared with a normal mount. And to further obscure the
>> issue, it also appears to depend on how much searching os-prober has to do
>> before finding out the information it needs, some distros like Devuan seem
>> to yield this quickly so there still isn't any real delay, but Arch takes
>> much longer and probably Windows too it appears.
>> I sometimes use gvfs-gphoto2 to transfer pictures and videos (some of which
>> may be several GB in size) from my camera which uses a FUSE implementation
>> and that doesn't have especially slow transfer speeds.
>> I wonder if you might be able to fix this sometime, or if you think the
>> issue lies outside of grub, provide advice on who to "bug" about this
>> instead.
>> Best wishes!
>>