Hello! Ricardo Wurmus <[email protected]> skribis:
> Ludovic Courtès <[email protected]> writes: > >> One way to work around the problem is to use PRoot, a ptrace(2)-based >> tool to virtualize the file system². With the ‘proot-static’ package I >> just pushed, one can run, say, hwloc, on such a hostile machine by >> sending locally-created packs as well as ‘proot’: >> >> scp $(guix build proot-static)/bin/proot hostile: >> scp $(guix pack hwloc -S /bin=bin) hostile:hwloc.tgz >> >> and then on the hostile machine: >> >> mkdir ~/.local >> cd ~/.local >> tar xf ~/hwloc.tgz >> cd >> ./proot -b .local:/ /bin/lstopo >> >> where “proot -b .local:/” essentially “bind-mounts” ~/.local to /. >> >> Pretty cool no? :-) > > That *is* very cool indeed! > >> PRoot adds overhead since it has to intercept every syscall. However, >> for a mostly computational process, it should not be much of a problem. > > Can this be simplified? We really only need that user-space bind-mount > feature, nothing else. PRoot does more than that IIUC. Can we preload > a little library that provides “open” and implementations of other file > access procedures, and simply (I know…) changes any access of “/gnu” > with the new target directory? > > I suspect this is doomed to fail because of the way shebangs work and > because we cannot interpose internal glibc calls, though. Ultimately, > ptrace really is what we want on Linux and sadly it’s just slow. Exactly. Many have written LD_PRELOADable libraries to perform file system virtualization but it’s tedious (there are so many VFS-related functions to interpose!) and fragile, and an application can always do a direct syscall and bypass the thing. So PRoot is not the preferred option, but it’s one we can resort to when there’s no other option. I have yet to measure its performance impact when running some of the linear algebra software that people use/develop here. > More power to the Hurd on HPC! :-) Ludo’.
