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