Jean-Yves F. Barbier a écrit : > Pascal Hambourg <[email protected]> a écrit : > >> Si j'étais vraiment obligé d'augmenter >> l'espace disque je préfèrerai ajouter un (ou remplacer le) disque >> interne, d'autant plus que la machine n'a que des ports USB 1.1. > > au pis aller ça passe très bien; parce que ce ne sont pas les transferts > qui prennent du temps.
Certes l'USB 1.1 reste 10 fois plus rapide que la connexion ADSL, et à peu près aussi rapide que la connexion ethernet côté LAN (flemme de remplacer la carte ethernet par une fast ethernet, pas très utile jusqu'ici). Mais 10 fois moins rapide qu'un disque interne sur cette machine (pas d'UDMA), par exemple ça ne doit pas être de la tarte pour rsync qui doit y lire les fichiers à synchroniser afin de les comparer à ceux de la source. > et dès fois tu n'as pas le choix (quand un gros HD bloque le BIOS, par > exemple) C'est fort probablement le cas vu l'âge de l'engin, mais il y a des contournements. Pour un disque secondaire, le déclarer absent dans le BIOS ne l'empêche pas d'être détecté et utilisé par Linux. Pour le disque de boot, définir manuellement une géométrie CHS fictive. >> rsync est efficace sur les fichiers .deb ? Intuitivement j'aurais plutôt >> tendance à penser qu'un fichier de type archive compressée ne s'y prête >> pas bien, mais je peux me tromper. > > Oui, rsync demande d'abord un md5sum au svr afin de décider s'il met à jour > ou non, donc quelque soit le type de ficher, ça marche :) On ne s'est pas bien compris, je crois. rsync ne télécharge que les fichiers modifiés, d'accord. Mais ma question portait sur les fichiers modifiés : rsync essaie de ne télécharger que les parties qui diffèrent, en tenant compte d'éventuels décalages. Pour du texte voire de l'exécutable ça peut être efficace, mais l'est-ce aussi pour une archive compressée comme un .deb ? Sinon je ne vois pas trop l'intérêt de rsync si c'est juste pour détecter les paquets qui ont changé, les méta-données d'APT suffisent. >> De toute façon 45 Go c'est trop, il faudrait des jours pour la >> synchronisation initiale du miroir alors qu'une infime partie serait >> utilisée. C'est pourquoi je privilégie plutôt un proxy/cache. Au fait, le total des CD ou DVD binaires pour i386 fait environ 20 Go, à quoi correspondent les 45 Go ? Si cela inclut les paquets sources, je n'en ai pas besoin. > cétoakivoa, disons que l'avantage de mirroirs complets c'est que la BP > n'est phagocytée qu'une seule fois par nuit et jamais plus par les machines > du LAN. > > évidemment, l'intérêt est directement proportionnel au nombre de machines à > mettre à jour simultanément. Une poignée seulement. Pas assez pour justifier un miroir. C'est surtout que la mise à jour de chaque machine télécharge les mêmes paquets à chaque fois, ce que je voudrais éviter. -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers [email protected] En cas de soucis, contactez EN ANGLAIS [email protected] Archive: http://lists.debian.org/[email protected]
