Bonjour à tous,
Je bosse actuellement sur un utilitaire permettant de télécharger des paquets.
Cet utilitaire permet d'obtenir la taille du paquet (pet ou sfs) avant son installation (lorsqu'il est compressé) et après son installation (lorsqu'il est décompressé) .
J'ai ajouté une fonction qui permet de comparer l'espace libre sur la partition d'accueil et la taille nécessaire pour l'installation du paquet.
Mon problème : je me questionne sur la taille nécessaire pour l'installation des paquets (pet et sfs).
Un exemple : je veux installer un paquet test.pet qui pèse 15 Mo (50Mo lorsque il est décompressé).
Je pense que pour permettre l'installation, il me faut prévoir sur la répertoire d'accueil (/root) : 15 Mo (la taille du paquet téléchargé temporairement dans /root) + 50 Mo (la taille du paquet décompressé temporairement dans /root) + 50 Mo (l'espace disque utilisé par les fichiers après installation) = 115 Mo nécessaires (temporairement) pour l'installation d'un paquet de 15 Mo.
Qu'en pensez-vous ?
Même question pour l'installation d'un sfs.
Merci d'avance pour l'aide que vous pourrez apporter à ma cogitation.
Cordialement,
Définir la taille nécessaire pour l'install d'un paquet
-
ASRI éducation
- Posts: 3197
- Joined: Sat 09 May 2009, 12:10
- Location: France
- Contact:
Définir la taille nécessaire pour l'install d'un paquet
Projet ASRI éducation => [url=http://asri-education.org/]Association[/url] | [url=http://forum.asri-education.org/]Forum[/url] | [url=http://dl01.asri-education.org/]Dépôt[/url] | [url=http://kids.asri-education.org/]Espace kids[/url]
Bonjour Asri,
Pour pouvoir t'aider il faut connaître la procédure d'installation !
Si ça se passe comme tu l'indiques et je penses que tu es certain de ce qui se passe, et bien ton raisonnement semble juste.
Tout ça paraît disproportionné mais l'addition finale est bien celle que tu indiques.
Bon, je n'aurai pas été d'une grande aide !
Philippe
Pour pouvoir t'aider il faut connaître la procédure d'installation !
Si ça se passe comme tu l'indiques et je penses que tu es certain de ce qui se passe, et bien ton raisonnement semble juste.
Tout ça paraît disproportionné mais l'addition finale est bien celle que tu indiques.
Bon, je n'aurai pas été d'une grande aide !
Philippe
Salut, ASRI.
Pas facile à trouver, cette information-là...
Trouvé ici : http://www.linuxjournal.com/node/8051/print que "gzip utilise
seulement 32 Ko de mémoire de travail pendant la compression." ("gzip uses only 32
kilobytes of working memory during compression,"). Concernant la décompression, je
n'ai trouvé aucune observation.
Comme les archives pet sont en réalité des tar.gz, reste à trouver la quantité de
"mémoire de travail" utilisée quand on "dé-tarre" un fichier.
L'utilitaire tar crée une copie d'un seul tenant des exécutables, etc., à (dé)compresser.
Donc déjà prévoir 2 fois la taille du fichier ou du dossier "à l'état naturel" pour avoir
l'espace nécessaire. Plus l'espace de travail nécessité par l'utilitaire tar lui-même, qui
est de ... on ne sait pas encore ...
Ce qui nous ferait : 2 x [taille du dossier à l'état naturel] + 32 Ko (?; pour l'utilitaire
gzip) + x (pour l'utilitaire tar)
Ton calcul à +/- 2,3 fois la taille de l'archive déballée semble logique. Maintenant, quel
genre de mémoire utilisera-t-on pour les fichiers de travail temporaires ? Mémoire de
masse (sur disque, genre fichier *.temp) ou mémoire vive ? Si le Toutou dispose de
suffisamment de MEV (RAM), pourrait-on déballer l'archive en MEV et avoir le résultat
désiré même avec un pupsave restreint ?
Si le tar pouvait être recréé en mémoire vive puis effacé après usage, pourrait-on s'en
tirer avec seulement 1,10 fois dans la mémoire de masse (pupsave ou partition) ?
Voilà pour le raisonnement logique. Reste maintenant à valider ce raisonnement par
des preuves ou des exemples dans la (ou les) documentation(s) !
Ou à défaut, des
tests ?
J'espère que ces quelques réflexions t'aideront.
À+
musher0
Pas facile à trouver, cette information-là...
Trouvé ici : http://www.linuxjournal.com/node/8051/print que "gzip utilise
seulement 32 Ko de mémoire de travail pendant la compression." ("gzip uses only 32
kilobytes of working memory during compression,"). Concernant la décompression, je
n'ai trouvé aucune observation.
Comme les archives pet sont en réalité des tar.gz, reste à trouver la quantité de
"mémoire de travail" utilisée quand on "dé-tarre" un fichier.
L'utilitaire tar crée une copie d'un seul tenant des exécutables, etc., à (dé)compresser.
Donc déjà prévoir 2 fois la taille du fichier ou du dossier "à l'état naturel" pour avoir
l'espace nécessaire. Plus l'espace de travail nécessité par l'utilitaire tar lui-même, qui
est de ... on ne sait pas encore ...
Ce qui nous ferait : 2 x [taille du dossier à l'état naturel] + 32 Ko (?; pour l'utilitaire
gzip) + x (pour l'utilitaire tar)
Ton calcul à +/- 2,3 fois la taille de l'archive déballée semble logique. Maintenant, quel
genre de mémoire utilisera-t-on pour les fichiers de travail temporaires ? Mémoire de
masse (sur disque, genre fichier *.temp) ou mémoire vive ? Si le Toutou dispose de
suffisamment de MEV (RAM), pourrait-on déballer l'archive en MEV et avoir le résultat
désiré même avec un pupsave restreint ?
Si le tar pouvait être recréé en mémoire vive puis effacé après usage, pourrait-on s'en
tirer avec seulement 1,10 fois dans la mémoire de masse (pupsave ou partition) ?
Voilà pour le raisonnement logique. Reste maintenant à valider ce raisonnement par
des preuves ou des exemples dans la (ou les) documentation(s) !
Ou à défaut, des tests ?
J'espère que ces quelques réflexions t'aideront.
À+
musher0
musher0
~~~~~~~~~~
"You want it darker? We kill the flame." (L. Cohen)
~~~~~~~~~~
"You want it darker? We kill the flame." (L. Cohen)
-
Médor
Bonjour,
Dans les scripts de petget (/usr/local/petget/) notamment dans le script install.sh il y a un calcul prenant en compte le poid du fichier pet (ou autres archives) à installer suivant le mode de fonctionnement de Puppy.
Pour l'expansion du paquet à installer depuis Puppy v3.01 l'espace disponible en ram doit être de trois fois la taille du paquet (contre cinq fois auparavant).
Bien qu'à présent dans les dernières versions de Woof CE, les paquets pet peuvent avoir une compression en xz (ainsi que les paquets slackware en tar.xz), l'espace libre en ram doit donc être supérieure à trois la taille du paquet
Naturellement si l'on installe un pet genre Open Office avec un PC ancien disposant de peu de ram il risque fort qu'il n'y ai pas assez d'espace libre en ram pour le télécharger puis l'expandre avant de déplacer finalement les fichiers dans l'arborescence soit en ram (livecd) soit dans le pupsave ou dans la partition.
Cordialement,
Médor.
Dans les scripts de petget (/usr/local/petget/) notamment dans le script install.sh il y a un calcul prenant en compte le poid du fichier pet (ou autres archives) à installer suivant le mode de fonctionnement de Puppy.
Pour l'expansion du paquet à installer depuis Puppy v3.01 l'espace disponible en ram doit être de trois fois la taille du paquet (contre cinq fois auparavant).
Bien qu'à présent dans les dernières versions de Woof CE, les paquets pet peuvent avoir une compression en xz (ainsi que les paquets slackware en tar.xz), l'espace libre en ram doit donc être supérieure à trois la taille du paquet
Naturellement si l'on installe un pet genre Open Office avec un PC ancien disposant de peu de ram il risque fort qu'il n'y ai pas assez d'espace libre en ram pour le télécharger puis l'expandre avant de déplacer finalement les fichiers dans l'arborescence soit en ram (livecd) soit dans le pupsave ou dans la partition.
Cordialement,
Médor.
-
ASRI éducation
- Posts: 3197
- Joined: Sat 09 May 2009, 12:10
- Location: France
- Contact:
Merci pour vos réponses qui vont me permettre de finaliser le script de téléchargement.
Cordialement,
Cordialement,
Projet ASRI éducation => [url=http://asri-education.org/]Association[/url] | [url=http://forum.asri-education.org/]Forum[/url] | [url=http://dl01.asri-education.org/]Dépôt[/url] | [url=http://kids.asri-education.org/]Espace kids[/url]