I have a system where there are quite a few internet-mounted (and therefore quite 'slow' on access) network drives. When portage completes compilation and moves to merging the package, it appears to be doing some checks to the network drives, causing quite a long delay before the actual merge happens. It would be useful if this could be disabled somehow, or some logic could be built into portage to prevent it from attempting to access these drives if they are not part of the merging paths. I tested and confirmed this delay issue does not occur if these specific network drives are not mounted. Reproducible: Always Steps to Reproduce: 1. Mount slow (seek/access times) network drives 2. Emerge a package 3. Actual Results: Portage can easily take 30-60 seconds before the actual merge happens. Expected Results: Merging the compiled package should happen immediately, because the network drives are not part of the merge paths.
I guess the obvious question is : What are your paths / mountpoints that cause this problem ?
(In reply to cyrillic from comment #1) > I guess the obvious question is : > What are your paths / mountpoints that cause this problem ? These are FTPFS (FUSE) mountpoints. They are in no way related to the normal operation of the OS: no libraries, binaries, etc. are stored there, and they are purely for backups / data storage.
Please share your `mount` output and `emerge --info`.
Created attachment 876601 [details] emerge --info
Sure, attachment above and mountpoints listed here. There is nothing particular about these mounts: they're strictly for backup/storage and slow because they use FUSE FTPFS. I suspect Portage is doing some kind of 'stat's on these mounts during the ebuilds' merge phase, which is quite slow for these internet mounts. It would be nice if Portage could be instructed not to do that for specific mounts, because the problem does not occur if the mounts are not active. Note: some pathnames snip'd for privacy, as well as a bunch of docker overlays: their presence does not influence the merge time, and all are under /var/lib/docker/. [...] Mount points [...] proc on /proc type proc (rw,nosuid,nodev,noexec,relatime) sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime) devtmpfs on /dev type devtmpfs (rw,nosuid,noexec,size=10240k,nr_inodes=8147971,mode=755) devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000) tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev,noexec) tmpfs on /run type tmpfs (rw,nosuid,nodev,noexec,mode=755) /dev/md126 on / type ext4 (rw,noatime,discard) securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime) debugfs on /sys/kernel/debug type debugfs (rw,nosuid,nodev,noexec,relatime) configfs on /sys/kernel/config type configfs (rw,nosuid,nodev,noexec,relatime) fusectl on /sys/fs/fuse/connections type fusectl (rw,nosuid,nodev,noexec,relatime) pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime) efivarfs on /sys/firmware/efi/efivars type efivarfs (rw,nosuid,nodev,noexec,relatime) none on /sys/fs/cgroup type cgroup2 (rw,nosuid,nodev,noexec,relatime,nsdelegate) mqueue on /dev/mqueue type mqueue (rw,nosuid,nodev,noexec,relatime) binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,nosuid,nodev,noexec,relatime) /dev/sdb1 on /boot type vfat (rw,noatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro,discard) /dev/sdc1 on /mnt/boot2 type vfat (rw,noatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro,discard) //192.168.2.222/storage on /storage type cifs (rw,relatime,vers=2.1,cache=strict,username=penguin,uid=1000,noforceuid,gid=100,noforcegid,addr=192.168.2.222,file_mode=0755,dir_mode=0755,iocharset=utf8,soft,nounix,serverino,mapposix,rsize=1048576,wsize=1048576,bsize=1048576,echo_interval=60,actimeo=1,closetimeo=1) /dev/sda1 on /mnt/<snip-5> type f2fs (rw,relatime,lazytime,background_gc=on,nogc_merge,nodiscard,no_heap,user_xattr,inline_xattr,acl,inline_data,inline_dentry,flush_merge,barrier,extent_cache,mode=adaptive,active_logs=6,alloc_mode=default,checkpoint_merge,fsync_mode=posix,compress_algorithm=lz4,compress_log_size=2,compress_mode=fs,memory=normal,errors=continue) tmpfs on /run/user/1000 type tmpfs (rw,nosuid,nodev,relatime,size=6519704k,nr_inodes=1629926,mode=700,uid=1000,gid=100) /dev/md126 on /var/lib/docker type ext4 (rw,noatime,discard) tmpfs on /run/user/0 type tmpfs (rw,nosuid,nodev,relatime,size=6519704k,nr_inodes=1629926,mode=700) curlftpfs#ftp://<snip-1>/ on /mnt/<snip-1> type fuse (ro,relatime,user_id=0,group_id=0) curlftpfs#ftp://<snip-1>/ on /mnt/<snip-2> type fuse (ro,relatime,user_id=0,group_id=0) curlftpfs#ftp://<snip-3>/ on /mnt/<snip-3> type fuse (ro,relatime,user_id=0,group_id=0) curlftpfs#ftp://<snip-4>/ on /mnt/<snip-4> type fuse (ro,relatime,user_id=0,group_id=0)
I'd be happy if there was at least a potential workaround for this. It's not a showstopper in the sense that Portage doesn't work, it just slows down the updating/installing quite a lot due to all the waiting at (practically every) ebuild merge :-)
> I'd be happy if there was at least a potential workaround for this. Presumably unmounting them before emerging works, right? Is this reproducible with something simple like `emerge --info`? Can you share the output of an `emerge --debug` that exhibits the hang? If you watch something like `htop` during the hang, are there any notable processes under `emerge`?
(In reply to John Helmert III from comment #7) > > I'd be happy if there was at least a potential workaround for this. > > Presumably unmounting them before emerging works, right? Yes, but that would also mean shutting down any running processes using those mounts, obviously. > Is this reproducible with something simple like `emerge --info`? Can you > share the output of an `emerge --debug` that exhibits the hang? If you watch > something like `htop` during the hang, are there any notable processes under > `emerge`? Not with emerge --info, and the emerge --debug is absolutely huge, output-wise (should I really attach the entire debug log here?). I checked with an `emerge --debug portage` (*) and it actually does not show any output during the 'hanging phase', but there is a notable 'I/O' wait increase in htop, probably because it's accessing those mountpoints. (*) Output: [...] + [[ config-protect-if-modified = \n\o\d\o\c ]] + for x in "$@" + [[ qa-unresolved-soname-deps = \n\o\d\o\c ]] + for x in "$@" + [[ sfperms = \n\o\d\o\c ]] + for x in "$@" + [[ usersandbox = \n\o\d\o\c ]] + for x in "$@" + [[ buildpkg-live = \n\o\d\o\c ]] + for x in "$@" + [[ userfetch = \n\o\d\o\c ]] + for x in "$@" + [[ parallel-fetch = \n\o\d\o\c ]] + return 1 + cd /var/tmp/portage/sys-apps/portage-3.0.56-r1/build-info + set -f + IFS=' ' + for f in INSTALL_MASK ++ echo -n + x= + [[ -n '' ]] + set +f + unset x + [[ -n '' ]] + [[ -n 1 ]] + [[ ! -s /var/tmp/portage/sys-apps/portage-3.0.56-r1/temp/sandbox-misc.log ]] + /var/tmp/portage/._portage_reinstall_.yx9cstgw/bin/ebuild-ipc exit 0 + : * checking 2824 files for package collisions [...] And it hangs for at least a good 15 seconds (sometimes >60s) at this point with no output, before it continues with the merge as normal: [...] >>> Merging sys-apps/portage-3.0.56-r1 to / + true + __qa_source /usr/portage/profiles/default/linux/amd64/17.1/profile.bashrc + local bashopts=checkwinsize:cmdhist:compat42:complete_fullquote:expand_aliases:extdebug:extquote:force_fignore:globasciiranges:globskipdots:hostcomplete:interactive_comments:progcomp:promptvars:sourcepath 'OLDIFS= ' + local retval + source /usr/portage/profiles/default/linux/amd64/17.1/profile.bashrc ++ [[ preinst == \s\e\t\u\p ]] + retval=0 + set +e + [[ checkwinsize:cmdhist:compat42:complete_fullquote:expand_aliases:extdebug:extquote:force_fignore:globasciiranges:globskipdots:hostcomplete:interactive_comments:progcomp:promptvars:sourcepath != \c\h\e\c\k\w\i\n\s\i\z\e\:\c\m\d\h\i\s\t\:\c\o\m\p\a\t\4\2\:\c\o\m\p\l\e\t\e\_\f\u\l\l\q\u\o\t\e\:\e\x\p\a\n\d\_\a\l\i\a\s\e\s\:\e\x\t\d\e\b\u\g\:\e\x\t\q\u\o\t\e\:\f\o\r\c\e\_\f\i\g\n\o\r\e\:\g\l\o\b\a\s\c\i\i\r\a\n\g\e\s\:\g\l\o\b\s\k\i\p\d\o\t\s\:\h\o\s\t\c\o\m\p\l\e\t\e\:\i\n\t\e\r\a\c\t\i\v\e\_\c\o\m\m\e\n\t\s\:\p\r\o\g\c\o\m\p\:\p\r\o\m\p\t\v\a\r\s\:\s\o\u\r\c\e\p\a\t\h ]] + [[ != \ \ \ ]] + return 0 [...]
(In reply to Arnim Eijkhoudt from comment #8) > ++ [[ preinst == \s\e\t\u\p ]] It looks like it's during pkg_setup, which corresponds to the linux-info_pkg_setup eclass function, and accesses your kernel sources. Are your kernel sources on a network drive?
(In reply to Zac Medico from comment #9) > (In reply to Arnim Eijkhoudt from comment #8) > > ++ [[ preinst == \s\e\t\u\p ]] > > It looks like it's during pkg_setup, which corresponds to the > linux-info_pkg_setup eclass function, and accesses your kernel sources. Are > your kernel sources on a network drive? They're not, they're in the normal location (/usr/src), which is not a network drive: [...] ┌──(root💀gateway)-[~] └─# ls -ald /usr/src/linux* lrwxrwxrwx 1 root root 18 Dec 3 19:51 /usr/src/linux -> linux-6.6.4-gentoo drwxr-xr-x 27 root root 4096 Dec 3 20:16 /usr/src/linux-6.6.4-gentoo [...]
