# emerge sync / verifizierung

## Murmeltier

Hallo zusammen und ein frohes neues Jahr

weiss jemand, ob und wie man das Verzeichnis ".tmp-unverified-download-quarantine" (wird beim sync-Vorgang benutzt) an einen anderen Ort als /var/portage/portage/... legen kann. Gefunden habe ich nichts, weder in der Konfiguration noch in den installierten portage-Dateien. Es scheint aber doch irgendwo hard-codiert zu sein.

Idealerweise würde ich es gerne in tmpfs ins ram verlegen, um den Verifizierungslauf zu beschleunigen.

(das Portage-Verzeichnis selber möchte ich so lassen wie es ist, sonst wär's einfach...)

Danke und Grüsse

----------

## soundrolf

Das Verzeichnis ist hier zu finden:

Verifying /usr/portage/.tmp-unverified-download-quarantine ...

Nach der Verifizierung wird dieses Verzeichnis wieder gelöscht.

----------

## Murmeltier

 *soundrolf wrote:*   

> Das Verzeichnis ist hier zu finden:
> 
> Verifying /usr/portage/.tmp-unverified-download-quarantine ...
> 
> Nach der Verifizierung wird dieses Verzeichnis wieder gelöscht.

 

Danke für die Antwort, aber das weiss ich schon.

Meine Absicht ist es, Portage dazu zu bringen, dieses Verzeichnis in /tmp anzulegen, insbesondere weil /tmp im RAM liegt.

Danach suche ich.

Gruss

----------

## mike155

Hallo Murmeltier und soundrolf,

vielen Dank für Euren Hinweis! Ich sehe /usr/portage/.tmp-unverified-download-quarantine heute zum ersten Mal.

Ich wundere mich schon lange, warum 'emerge --sync' auf meinen Clients, die /usr/portage über NFS gemoutet haben, so unglaublich lange dauert. Ich hatte das nie näher untersucht und ich dachte, dass es vielleicht Verzögerungen beim Lesen von Dateien über NFS sind.

Jetzt schaue ich nach /usr/portage/.tmp-unverified-download-quarantine und muss feststellen, dass dort bei einem 'emerge --sync' erst einmal 160.000 Dateien angelegt werden? Kein Wunder, dass das über NFS so lange dauert!

Was erlauben sich Portage???

Ja, ich habe auch sehr großes Interesse daran, dieses Verzeichnis - wenn es denn überhaupt gebraucht wird - schnellstmöglich auf ein tmpfs umzulegen.

----------

## mike155

Der Code, mit dem /usr/portage/.tmp-unverified-download-quarantine angelegt wird, steht in 

```
portage-2.3.X/lib/portage/repository/storage/hardlink_quarantine.py

```

Dort steht auch mehr darüber, warum das Unterverzeichnis angelegt wird:

```
class HardlinkQuarantineRepoStorage(RepoStorageInterface):

        """

        This is the default storage module, since its quite compatible with

        most configurations.

        It's desirable to be able to create shared hardlinks between the

        download directory and the normal repository, and this is facilitated

        by making the download directory be a subdirectory of the normal

        repository location (ensuring that no mountpoints are crossed).

        Shared hardlinks are created by using the rsync --link-dest option.

        Since the download is initially unverified, it is safest to save

        it in a quarantine directory. The quarantine directory is also

        useful for making the repository update more atomic, so that it

        less likely that normal repository location will be observed in

        a partially synced state.

        """

```

Der Code arbeitet mit Hard Links, was schon mal gut ist, weil keine Dateien kopiert werden - aber es dauert über NFS trotzdem sehr lange.

Und weil der Code mit Hard Links arbeitet, wird es nicht möglich sein, /usr/portage/.tmp-unverified-download-quarantine auf ein anderes Volume (z.B. ein tmpfs-Volume) zu mounten. Das dürfte die Antwort auf die Frage von Murmeltier sein.

Mich interessiert, warum dieses temporäre Verzeichnis überhaupt nötig ist:

Kann man 'emerge --sync' dazu bringen, ohne /.tmp-unverified-download-quarantine - und damit direkt auf /usr/portage - zu arbeiten?

Hätte dies irgendwelche gravierenden Nachteile (außer dass /usr/portage bei einem Fehler unbrauchbar wird)?

----------

## Max Steel

Ich würde vorschlagen den Sync einmal auf dem NFS Host laufen zu lassen und die Clients mit dieser Aufgabe in Frieden zu lassen.

Das hilft deutlich bei deinem ursprünglichen Problem dass die NFS Clients langsam sind. der Ordner hat was damit zu tun um nachträgliche Manipulationen im übertragenen Portagestream zu erkennen und xzu verifizieren dass du auch tatsächlich mit dem portage-tree-repo redest von dem du glaubst dass der da liegt auf dem Server mit dem du redest.

Man kann diesen Test auch deaktivieren (afaik) aber ich weiß gerade nicht akut wie.

----------

## mike155

 *Quote:*   

> Man kann diesen Test auch deaktivieren (afaik) aber ich weiß gerade nicht akut wie.

 

Ja das stimmt. Wie es geht, steht in dem News Item. Beide Methoden verhindern die Verifizierung.  Aber sie verhindern nicht, dass das Unterverzeichnis /.tmp-unverified-download-quarantine angelegt und mit Verzeichnissen und 160.000 Hard Links bestückt wird.

 *Quote:*   

> Ich würde vorschlagen den Sync einmal auf dem NFS Host laufen zu lassen und die Clients mit dieser Aufgabe in Frieden zu lassen. 

 

Das mache ich gelegentlich auch, wenn ich es eilig habe.  :Smile:  Aber ich arbeite meistens auf einem Client-Rechner und würde Portage eben auch gerne dort performant laufen lassen. Bisher hat es mich nicht gestört, dass es länger dauert. Aber jetzt, wo ich weiß, dass Portage Quatsch macht, stört es mich!

Ich kann mir nicht vorzustellen, dass der Algorithmus "lege erst einmal ein Unterverzeichnis mit 160.000 Hard Links an" auf einem NFS Host oder auf überhaupt irgendeinem Rechner sinnvoll ist. Von daher interessiert es mich, warum es so implementiert wurde und ob es Alternativen gibt - die vielleicht sogar schon in Portage schlummern und durch entsprechende Optionen zum Leben erweckt werden können.

----------

## mike155

'emerge --sync' legt das Verzeichnis /usr/portage/.tmp-unverified-download-quarantine und die darin enthaltenen Verzeichnisse und Dateien (Hard Links) mit rsync an:

```
rsync -a \

    --link-dest /usr/portage \

    --exclude=/distfiles \

    --exclude=/local \

    --exclude=/lost+found \

    --exclude=/packages \

    --exclude /.tmp-unverified-download-quarantine \

    /usr/portage/ \

    /usr/portage/.tmp-unverified-download-quarantine/

```

Je nachdem, ob ich diese rsync-Anweisung auf meinem NFS Server oder auf meinem NFS Client ausführe, erhalte ich:

```
+------------------------------------------+--------------+--------------+

|                                          |   NFS Server |   NFS Client |

+------------------------------------------+--------------+--------------+

| Ausführungszeit obige rsync-Anweisung    |   3 Sekunden | 344 Sekunden |

| Benötigter Plattenplatz                  |       111 MB |       111 MB |

| Anzahl anlegte Verzeichnisse             |       27.000 |       27.000 |

| Anzahl angelegte Dateien (hard links)    |      136.000 |      136.000 |

| Ausführungszeit für Löschen              | 1.5 Sekunden | 113 Sekunden |

|   (rm -rf /usr/portage/.tmp-unveri..)    |              |              |

+------------------------------------------+--------------+--------------+

```

Ich warte auf meinen NFS Client also fast 8 Minuten nur für das Anlegen und Löschen einer temporären Kopie von /usr/portage!!!

Das erklärt dann natürlich meine Beobachtung für die Ausführungszeit von 'emerge --sync':

```
+------------------------------------------+--------------+--------------+

|                                          |   NFS Server |   NFS Client |

+------------------------------------------+--------------+--------------+

| Ausführungszeit 'emerge --sync'          |  13 Sekunden | 598 Sekunden |

+------------------------------------------+--------------+--------------+

```

Da muss es doch eine sehr viel bessere Lösung geben!

----------

## Max Steel

ich hab mich glaube ich etwas falsch ausgedrückt:

 *Quote:*   

> Ich würde vorschlagen den Sync einmal auf dem NFS Host laufen zu lassen und die Clients mit dieser Aufgabe in Frieden zu lassen.

 

Ich meinte damit eigentlich "lass die Clients damit in Frieden und mach einen Cronjob auf dem Host der regelmäßig den Tree in Sync hält.

Oder eben die Verify Funktion deaktivieren.

----------

## Murmeltier

 *mike155 wrote:*   

> Der Code, mit dem /usr/portage/.tmp-unverified-download-quarantine angelegt wird, steht in 
> 
> ```
> portage-2.3.X/lib/portage/repository/storage/hardlink_quarantine.py
> 
> ...

 

Hallo mike155,

danke, das habe ich gesucht!

def init_update(self):

  update_location = os.path.join(self._user_location, '.tmp-unverified-download-quarantine')

Schade, dass man wegen der Hardlinks nicht einen anderen Mount-Punkt nehmen kann,

jetzt könnte ich noch den ganzen Tree auf der SSD vorhalten, aber das scheint mir auch

nicht so die beste Idee zu sein bei der grossen Zahl von Schreibzugriffen.

Danke für die Info!

----------

## mike155

Noch ein Nachtrag: man kann das Verzeichnis ".tmp-unverified-download-quarantine" wohl nicht an einen anderen Ort legen.

Anon-E-Moose hat aber in einem anderen Thread eine Lösung gezeigt, wie man verhindern kann, dass es überhaupt angelegt wird: https://forums.gentoo.org/viewtopic-p-8304296.html#8304296

Hierzu gibt es auch ein News-Item: https://www.gentoo.org/support/news-items/2018-07-11-portage-sync-allow-hardlinks.html

----------

## flammenflitzer

Ich muss das Thema noch einmal aufwärmen. Ich habe gerade versucht, den Portage Tree nach ca. 7 Wochen zu synchronisieren. Dabei ging mein System in die Knie. Nach ca. einer halben Stunde 

```
Verifying /usr/portage/.tmp-unverified-download-quarantine ... 
```

 musste ich mein System über Alt+Druck+... abschießen, weil die Systemlast so hoch war, das gar nichts mehr ging.

```
emerge --info

Portage 2.3.51 (python 3.6.5-final-0, default/linux/amd64/17.0/desktop/plasma/systemd, gcc-7.3.0, glibc-2.27-r6, 4.14.83-gentoo x86_64)

=================================================================

System uname: Linux-4.14.83-gentoo-x86_64-Intel-R-_Core-TM-_i5-3330_CPU_@_3.00GHz-with-gentoo-2.6

KiB Mem:     8044572 total,   6061188 free

KiB Swap:    9301628 total,   9301628 free

Timestamp of repository gentoo: Sat, 23 Feb 2019 07:00:01 +0000

Head commit of repository gentoo: d3ad48cc7e165cea71380a0243264fcf5f0a290a

sh bash 4.4_p12

ld GNU ld (Gentoo 2.30 p5) 2.30.0

app-shells/bash:          4.4_p12::gentoo

dev-java/java-config:     2.2.0-r4::gentoo

dev-lang/perl:            5.26.2::gentoo

dev-lang/python:          2.7.15::gentoo, 3.6.5::gentoo

dev-util/cmake:           3.9.6::gentoo

dev-util/pkgconfig:       0.29.2::gentoo

sys-apps/baselayout:      2.6-r1::gentoo

sys-apps/sandbox:         2.13::gentoo

sys-devel/autoconf:       2.13-r1::gentoo, 2.69-r4::gentoo

sys-devel/automake:       1.11.6-r3::gentoo, 1.12.6-r2::gentoo, 1.13.4-r2::gentoo, 1.15.1-r2::gentoo, 1.16.1-r1::gentoo

sys-devel/binutils:       2.30-r4::gentoo

sys-devel/gcc:            7.3.0-r3::gentoo

sys-devel/gcc-config:     2.0::gentoo

sys-devel/libtool:        2.4.6-r3::gentoo

sys-devel/make:           4.2.1-r4::gentoo

sys-kernel/linux-headers: 4.14-r1::gentoo (virtual/os-headers)

sys-libs/glibc:           2.27-r6::gentoo

Repositories:

gentoo

    location: /usr/portage

    sync-type: rsync

    sync-uri: rsync://rsync.gentoo.org/gentoo-portage

    priority: -1000

    sync-rsync-extra-opts: 

    sync-rsync-verify-jobs: 1

    sync-rsync-verify-max-age: 24

    sync-rsync-verify-metamanifest: yes

local

    location: /usr/local/portage/local

    masters: gentoo

    priority: 0

grub2-themes

    location: /var/lib/layman/grub2-themes

    masters: gentoo

    priority: 50

ACCEPT_KEYWORDS="amd64"

ACCEPT_LICENSE="*"

CBUILD="x86_64-pc-linux-gnu"

CFLAGS="-march=corei7 -O2 -pipe"

CHOST="x86_64-pc-linux-gnu"

CONFIG_PROTECT="/etc /usr/share/config /usr/share/gnupg/qualified.txt /usr/share/themes/oxygen-gtk/gtk-2.0"

CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/dconf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo"

CXXFLAGS="-march=corei7 -O2 -pipe"

DISTDIR="/usr/portage/distfiles"

EMERGE_DEFAULT_OPTS="--autounmask=n"

ENV_UNSET="DBUS_SESSION_BUS_ADDRESS DISPLAY GOBIN PERL5LIB PERL5OPT PERLPREFIX PERL_CORE PERL_MB_OPT PERL_MM_OPT XAUTHORITY XDG_CACHE_HOME XDG_CONFIG_HOME XDG_DATA_HOME XDG_RUNTIME_DIR"

FCFLAGS="-O2 -pipe"

FEATURES="assume-digests binpkg-logs config-protect-if-modified distlocks ebuild-locks fixlafiles merge-sync multilib-strict news parallel-fetch preserve-libs protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync xattr"

FFLAGS="-O2 -pipe"

GENTOO_MIRRORS="http://ftp.spline.inf.fu-berlin.de/mirrors/gentoo/ http://mirrors.sec.informatik.tu-darmstadt.de/gentoo/ http://linux.rz.ruhr-uni-bochum.de/download/gentoo-mirror/ http://ftp.uni-erlangen.de/pub/mirrors/gentoo"

LANG="de_DE.UTF-8"

LDFLAGS="-Wl,-O1 -Wl,--as-needed"

LINGUAS="de_DE de"

PKGDIR="/usr/portage/packages"

PORTAGE_CONFIGROOT="/"

PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --omit-dir-times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --exclude=/.git"

PORTAGE_TMPDIR="/var/tmp"

USE="64bit X a52 aac aalib acl acpi activities alsa amd64 berkdb bluetooth bluray branding bzip2 cairo cdda cddb cdparanoia cdr cdrom cli crypt cups cxx dbus declarative dga dhcp dri dts dv dvbpsi dvd dvdr emboss encode equalizer exif fam ffmpeg flac fortran gdbm gif glamor gpm gtk iconv ios ipv6 joystick jpeg jpeg2k kde kipi kwallet lcms ldap libnotify libsamplerate libtirpc linguas_de linguas_de_DE mad matroska mjpeg mmxext mng mobi mp3 mp4 mpeg mtp multilib musicbrainz ncurses nls nptl nvidia ogg opencl opengl openmp pam pango pcre pdf phonon plasma png policykit ppds pulseaudio qml qt4 qt5 quicktime raw readline rtc scanner sdl seccomp semantic-desktop shorten socks5 spell ssl startup-notification svg systemd tcpd theora tiff truetype udev udisks unicode upnp upower usb vcd vdpau vorbis widgets wifi wxwidgets x264 xattr xcb xcomposite xinerama xml xv xvid xvmc zlib" ABI_X86="64 32" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" APACHE2_MODULES="authn_core authz_core socache_shmcb unixd actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CALLIGRA_FEATURES="braindump karbon krita words sheets stage" CAMERAS="adc65 agfa_cl20 aox ax203 barbie canon casio_qv clicksmart310 digigr8 digita dimagev dimera3500 directory enigma13 fuji gsmart300 hp215 iclick jamcam jd11 jl2005a jl2005c kodak_dc120 kodak_dc210 kodak_dc240 kodak_dc3200 kodak_ez200 konica konica_qm150 largan lg_gsm mars mustek panasonic_coolshot panasonic_dc1000 panasonic_dc1580 panasonic_l859 pccam300 pccam600 pentax polaroid_pdc320 polaroid_pdc640 polaroid_pdc700 ptp2 ricoh ricoh_g3 samsung sierra sipix_blink sip sipix_blink2 sipix_web2 smal sonix sony_dscf1 sony_dscf55 soundvision spca50x sq905 st2205 stv0674 stv0680 sx330z template topfield toshiba_pdrm11 tp6801" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" CPU_FLAGS_X86="aes avx f16c mmx mmxext pclmul popcnt sse sse2 sse3 sse4_1 sse4_2 ssse3" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock isync itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf skytraq superstar2 timing tsip tripmate tnt ublox ubx" GRUB_PLATFORMS="emu efi-32 efi-64 pc" INPUT_DEVICES="evdev keyboard joystick mouse" KERNEL="linux" L10N="de" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" LIRC_DEVICES="devinput" NETBEANS_MODULES="apisupport cnd groovy gsf harness ide identity j2ee java mobility nb php profiler soa visualweb webcommon websvccommon xml" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php5-6 php7-1" POSTGRES_TARGETS="postgres9_5 postgres10" PYTHON_SINGLE_TARGET="python3_6" PYTHON_TARGETS="python2_7 python3_6" RUBY_TARGETS="ruby22 ruby23 ruby24" SANE_BACKENDS="canon pixma" USERLAND="GNU" VIDEO_CARDS="vesa nvidia" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account"

Unset:  CC, CPPFLAGS, CTARGET, CXX, INSTALL_MASK, LC_ALL, MAKEOPTS, PORTAGE_BINHOST, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS

```

----------

## mike155

Flammenflitzer, ich habe keine Idee, warum bei Dir eine so hohe Last auf dem System entstanden ist. Bei mir hat es auf den NFS Clients einfach nur sehr lange gedauert - ohne hohe Last. 

1) Welches Dateisystem verwendest Du in /usr/portage? Hast Du dort irgendwelche Besonderheiten? 

2) Du könntest die oben gezeigte rsync-Anweisung mal von Hand ausführen und überprüfen, ob Du den Effekt damit reproduzieren kannst.

3) Ich habe den Verify-Schritt auf meinen Rechnern ausgeschaltet:

Ich habe das Paket 'portage' ohne USE flag 'rsync-verify' installiert

Ich habe folgende zwei Zeilen an die 'DEFAULT' section von /etc/portage/repos.conf/gentoo.conf hinzugefügt:

```
sync-rsync-verify-metamanifest = no

sync-allow-hardlinks = no
```

----------

## flammenflitzer

Muss ich beobachten. Ich habe es noch einmal gestartet und bin zwischendurch in den Baumarkt gefahren. Als ich zurück kam war die Sache durch.   :Wink: 

----------

