# [portage] partition dédiée : quelle taille ?

## gbetous

salut !

Je me demande quelle taille donner à une partition dédiée à l'arbre portage. Déjà, j'ai choisi comme FS ReiserFS, réputé pour son aisance avec les petits fichiers très nombreux.

Ensuite, je sais pas trop si j'y inclus le répertoire distfiles ou pas. Dans le cas où je le laisse, est-ce que 5Go semblent suffisants ? Au bout de combien de temps les fichiers de distfiles sont-ils éffacés (j'avoue ne m'en etre jamais occupé) ?

----------

## geekounet

J'ai mis 1Go en XFS, et ça semble être ce qu'il faut, et ça prévoit de la place pour plus tard.

```
$ df -h /var/portage/

Filesystem            Size  Used Avail Use% Mounted on

/dev/sda9             961M  595M  366M  62% /var/portage
```

J'avais essayé avec seulement 700Mo, mais j'ai pas pu finir mon sync, il disait que la partition était pleine.

J'ai mis les distfiles à part dans /var/distfiles/ (oui je sais j'ai pas des paths conventionnel, mais je trouve ça plus logique comme ça)

```
$ du -sh /var/distfiles/

2,4G   /var/distfiles/
```

Voilà  :Smile: 

EDIT: et j'ai fais un eclean pour les distfiles juste avant

----------

## titoucha

 *gbetous wrote:*   

> Ensuite, je sais pas trop si j'y inclus le répertoire distfiles ou pas. Dans le cas où je le laisse, est-ce que 5Go semblent suffisants ? Au bout de combien de temps les fichiers de distfiles sont-ils éffacés (j'avoue ne m'en etre jamais occupé) ?

 

Il me semble que si tu ne fais pas declean les fichiers dans distfiles ne sont pas effacés.

----------

## netfab

Partition dédiée pour portage en reiserfs : 512 Mo :

```

Sys. de fich.         Tail. Occ. Disp. %Occ. Monté sur

/dev/hdb6             495M  241M  254M  49% /var/portage
```

partition dédiée en ext3 pour distfiles et packages : un peu plus de 6 Go

```

Sys. de fich.         Tail. Occ. Disp. %Occ. Monté sur

/dev/hdb7             6,1G  3,6G  2,3G  62% /distpack
```

----------

## geekounet

 *NetFab wrote:*   

> Partition dédiée pour portage en reiserfs : 512 Mo :
> 
> ```
> 
> Sys. de fich.         Tail. Occ. Disp. %Occ. Monté sur
> ...

 

o_O'

Bon ben je penserai à la passer en reiser4 à l'occasion  :Smile:  (mauvaises expériences avec le reiserfs, donc je le prend pas  :Razz: )

----------

## blasserre

 *geekounet wrote:*   

>  *NetFab wrote:*   Partition dédiée pour portage en reiserfs : 512 Mo :
> 
> ```
> 
> Sys. de fich.         Tail. Occ. Disp. %Occ. Monté sur
> ...

 

d'autant que sur des petits fichiers xfs galère un max... enfin chez moi   :Embarassed:  mais avec les options qui tuent d'Enlight   :Cool: 

----------

## -KuRGaN-

Sinon tu peux jouer avec lvm si tu n'es pas trop sur de la taille de partition !!

----------

## gbetous

lvm ? pourquoi pas, ca me fera un bon exercice (c'est pas la mort si je me vautre et que je pète tout)/

pour l'instant je suis avec une partition de 5Go ReiserFS dans laquelle je laisse les distfiles.

au passage, merci pour le eclean, je ne manquerai pas d'en faire régulièrement !!!

----------

## titoucha

Si tu utilises régulièrement eclean tu n'as vraiment pas besoin d'autant de place, j'ai 956 fichiers pour 1.6G.

----------

## geekounet

Bon bah voilà, avant de faire mon emerge -e world pour réparer mes conneries et puis au passage retrouver un système propre, je me suis dis que c'était une bonne idée de repartitionner mes partoches /var/portage et /var/tmp en reiser4 (et au final mon /var est séparé en 4 avec le /var/distfiles en XFS que j'ai voulu mettre à part aussi), ça donne ça au final en montant tout  :Smile:  :

```
Filesystem    Type    Size  Used Avail Use% Mounted on

/dev/sda5      xfs    247M  107M  140M  44% /

udev         tmpfs    248M  188K  247M   1% /dev

/dev/sda6      xfs    490M  532K  489M   1% /tmp

/dev/sda7      xfs    5,6G  4,9G  747M  87% /usr

/dev/sda8      xfs    490M  360M  130M  74% /var

/dev/sda9  reiser4    470M  187M  284M  40% /var/portage

/dev/sda10     xfs    3,3G  2,5G  844M  75% /var/distfiles

/dev/sda11 reiser4    4,0G   64M  3,9G   2% /var/tmp

/dev/sda12     xfs     41G   31G   10G  76% /home

shm          tmpfs    248M     0  248M   0% /dev/shm

svcdir       tmpfs    2,0M  252K  1,8M  13% /var/lib/init.d

/dev/sda2     ext2     38M  3,1M   33M   9% /boot

/dev/sda1     vfat     87M  7,2M   79M   9% /media/dell
```

(et /dev/sda3 de 512Mo pour la swap)

Effectivement, la partoche de portage en reiser4, ça prend bien moins de place : moins de 200Mo en reiser4 contre plus de 600Mo en XFS avant. J'ai pas testé de sync, mais je pense que ça devrait passer à l'aise. Et le /var/tmp en reiser4 aussi, ça aide bien pour les compilations, entre les décompressions de grosses archives et la deletion du répertoire de travail en fin d'emerge, c'est bien mieux  :Smile: 

Voilà  :Smile:  C'est peut-être excessif de séparer autant, mais je trouve ça sympa ^^

----------

## blasserre

 *geekounet wrote:*   

> Voilà  C'est peut-être excessif de séparer autant, mais je trouve ça sympa ^^

 

haaaaaahaaaaaaaaaaa ! mes yeux .....   :Laughing: 

excessif ? noooonnnn.... moi qui me croyais vicieux j'ai trouvé mon maitre  :Mr. Green: 

----------

## titoucha

Alors là, je dis qu'il y a du masochisme dans l'air.  :Laughing: 

----------

## man in the hill

 *titoucha wrote:*   

> Alors là, je dis qu'il y a du masochisme dans l'air. 

 

C'est la voie du geek   :Wink:   :Very Happy:  .

----------

## titoucha

Alors je ne suis pas encore un bon geek   :Wink: 

----------

## E11

Il é fou !!  :Razz: 

Personnellement avant j'utilisais lvm, et je faisais je ne sais plus combien de milliers de partitions (bcp hein ?  :Razz: ) pour chaque partie du système,... mais après avoir craché plusieurs partitions pour "cause de mauvaise manipulation"  :Very Happy:   :Embarassed:  j'ai arrêté et j'ai tout remis sur une partition classic  :Laughing: 

Il faut dire, c'est plus pratique aussi quand on doit se chrooter d'un livecd pour je ne sais quel raison... 

Et puis, mes pertes de partitions ont beaucoup diminées depuis  :Rolling Eyes:  je me demande d'ailleurs toujours pourquoi   :Rolling Eyes: 

----------

## Oupsman

Marrant ca, depuis que j'ai mon serveur j'ai jamais crashé de partoche. Et je suis en LVM :

```

Filesystem         1024-blocks      Used Available Capacity Mounted on

/dev/hda3              9775248   7778776   1996472      80% /

udev                    516944       204    516740       1% /dev

none                    516944         0    516944       0% /dev/shm

/dev/mapper/rootvg-apache  83883516  54938480  28945036      66% /var/www

/dev/mapper/rootvg-mysqllv  10485436   6646284   3839152      64% /var/lib/mysql

/dev/mapper/rootvg-cvslv   1048540    182380    866160      18% /var/lib/cvsd

/dev/mapper/rootvg-partagevg 157281596 112642936  44638660      72% /home/partage

/dev/mapper/rootvg-vpopmaillv   5222036    548440   4673596      11% /var/vpopmail/domains

/dev/mapper/rootvg-filmslv  31456316  29284040   2172276      94% /home/films

/dev/mapper/rootvg-movieslv 104854396  78677628  26176768      76% /home/movies

/dev/mapper/rootvg-photoslv  10485436   5011764   5473672      48% /home/photos

/dev/mapper/rootvg-vserverslv   2097084   1682364    414720      81% /vservers

/dev/mapper/rootvg-oupsmanlv   5222036   1689124   3532912      33% /home/oupsman

/dev/mapper/rootvg-distfileslv   5242716    932092   4310624      18% /usr/portage/distfiles

/dev/mapper/rootvg-squidcachelv   2097084    130028   1967056       7% /var/cache/squid

/dev/mapper/rootvg-disklesslv   5242716   2974680   2268036      57% /diskless

ourson ~ # mount

/dev/hda3 on / type reiserfs (rw,noatime)

proc on /proc type proc (rw)

sysfs on /sys type sysfs (rw,nosuid,nodev,noexec)

udev on /dev type tmpfs (rw,nosuid)

devpts on /dev/pts type devpts (rw,nosuid,noexec)

none on /dev/shm type tmpfs (rw)

/dev/mapper/rootvg-apache on /var/www type reiserfs (rw,noatime)

/dev/mapper/rootvg-mysqllv on /var/lib/mysql type reiserfs (rw,noatime)

/dev/mapper/rootvg-cvslv on /var/lib/cvsd type reiserfs (rw,noatime)

/dev/mapper/rootvg-partagevg on /home/partage type reiserfs (rw,noatime)

/dev/mapper/rootvg-vpopmaillv on /var/vpopmail/domains type jfs (rw,noatime)

/dev/mapper/rootvg-filmslv on /home/films type reiserfs (rw,noatime)

/dev/mapper/rootvg-movieslv on /home/movies type reiserfs (rw,noatime)

/dev/mapper/rootvg-photoslv on /home/photos type reiserfs (rw,noatime)

/dev/mapper/rootvg-vserverslv on /vservers type reiserfs (rw,noatime)

/dev/mapper/rootvg-oupsmanlv on /home/oupsman type jfs (rw,noatime)

/dev/mapper/rootvg-distfileslv on /usr/portage/distfiles type reiserfs (rw,noatime)

/dev/mapper/rootvg-squidcachelv on /var/cache/squid type reiserfs (rw,noatime)

/dev/mapper/rootvg-disklesslv on /diskless type reiserfs (rw,noatime)

usbfs on /proc/bus/usb type usbfs (rw,noexec,nosuid,devmode=0664,devgid=85)

binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,noexec,nosuid,nodev)

nfsd on /proc/fs/nfs type nfsd (rw)

rpc_pipefs on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)

```

Moi fou furieux ?

----------

## titoucha

Quel est le vrai avantage de faire autant de partitions différentes, pour certaines d'entre elles je vois, séparer le / du /home, mais pour d'autres c'est moins évident pour moi.

PS: A part le fun bien entendu.

----------

## Oupsman

J'avoue que cette habitude de séparer au maximum comme ça me vient de mon travail, où j'ai parfois des bécanes gérant 6 To de données et quasiment 300 filesystems. Sous AIX, donc tout géré par LVM.

L'interêt principal étant de maximiser les performances, étant donné que tes disques tournent tous ensemble. Quand j'ai débuté sous Unix, une préconisation était de créer / sur un disque et /usr sur un autre (et éventuellement la swap a cheval sur les 3 disques) L'autre avantage étant si jamais tu oublies de faire du ménage dans /usr/portage/distfiles, avoir un FS dédié pour cela évite de remplir le /, ce qui peut s'avérer génant dans certaines conditions. 

[déviation]

L'avantage flagrant de la LVM pour cela est que ton plan de partitionnement n'est pas figé. Le /tmp est plein ? Pas grave, tu augmentes. Ah merde, j'ai mis trop dans le /home et pas assez dans /usr ? Pas grave, pour peu que le /home soit en reiserfs, tu démontes, diminue le /home et augmente le /usr. Cela apporte une certaine souplesse dans la gestion de son stockage, souplesse bien appréciable. Pour information, j'ai 580 Go de stockage dans mon serveur. Quand j'ai créé mon média center, je l'ai mis sous LVM, histoire de séparer un peu les fonctions : films, musique, photos ... Et mon serveur XEN est aussi sous LVM car XEN supporte l'utilisation d'un Logical Volume comme disque virtuel, ce qui est très très pratique. On peut même, en créant à la volée un LV, l'ajouter dynamiquement dans la partition et donc augmenter le stockage de la partition.

[/déviation]

----------

## dapsaille

 *Oupsman wrote:*   

> Marrant ca, depuis que j'ai mon serveur j'ai jamais crashé de partoche. Et je suis en LVM :
> 
> ```
> 
> Filesystem         1024-blocks      Used Available Capacity Mounted on
> ...

 

 GNaaaaaaaa !!!!! je vais l'imprimer sur un tee shirt "let me be a geek"   :Laughing:   :Laughing: 

----------

## Oupsman

Moquez vous moquez vous   :Laughing:   :Laughing:   :Laughing: 

----------

## Enlight

 *Quote:*   

> enlight@Unicorn ~ $ df -h
> 
> Sys. de fich.         Tail. Occ. Disp. %Occ. Monté sur
> 
> /dev/sda6             5,6G  3,1G  2,5G  56% /
> ...

 

Avec distfiles donc. pour les petits fichiers c'est sur que les tails des reisers peuvent être un plus, mais on peut aussi envisager un autre FS avec un blocksize de 1ko au lieu de 4, ça devrait déja bien limiter le gachi. (j'vais faire ça tient et voir combien je gagne, je reposterai)

@ Oupsman : mais t'es pas bien???   :Very Happy:  Moi si je devais retenir autant de points de montage j'aurais même plus assez de mémoire pour me rappeler comment je m'appele!!!

----------

## Oupsman

Et encore, je viens de me rendre compte que le fs pour mon serveur tftp (pratique pour faire des installations via PXE sur un PC sans CD) n'était pas monté, donc que c'était normal que cette foutue merde d'installation de ubuntu voulait pas fonctionner ....

----------

## geekounet

Le /var/tmp en reiser4 à fait ses preuves  :Smile:  :

```
     Sat Oct 14 06:56:43 2006 >>> app-office/openoffice-2.0.4

       merge time: 7 hours, 11 minutes and 52 seconds.          <== XFS

     Sun Nov  5 06:53:06 2006 >>> app-office/openoffice-2.0.4

       merge time: 5 hours, 22 minutes and 17 seconds.          <== Reiser4
```

Soit ~2h de gain à la compilation d'openoffice  :Smile: 

(Oui j'ai compilé OOo juste pour tester et alors ?  :Razz: )

----------

## blasserre

 *geekounet wrote:*   

> Le /var/tmp en reiser4 à fait ses preuves  :
> 
> ```
>      Sat Oct 14 06:56:43 2006 >>> app-office/openoffice-2.0.4
> 
> ...

 

tu m'étonnes john !

c'est ce que je disais l'autre jour, quand on voit les temps de nettoyage pour des petits paquets (quelques Mo de sources) on a vraiment plus envie de laisser ce répertoire en XFS.... idem pour /usr/portage.

----------

## titoucha

Je ne pensais pas qu'un fs pouvait avoir une pareil incidence sur une compilation, c'est vraiment impressionnant.

----------

## geekounet

 *titoucha wrote:*   

> Je ne pensais pas qu'un fs pouvait avoir une pareil incidence sur une compilation, c'est vraiment impressionnant.

 

En fait, c'est pas vraiment sur la compilation mais plutôt la décompression des archives et la suppression du répertoire de travail à la fin (4-5 Go).

----------

## neysx

 *geekounet wrote:*   

> Le /var/tmp en reiser4 à fait ses preuves  :
> 
> ```
>      Sat Oct 14 06:56:43 2006 >>> app-office/openoffice-2.0.4
> 
> ...

 C'est sûr qu'avec des benchmarks à la con comme ça, le mythe du reiser-ki-va-mieux a encore de beaux jours devant lui.

```
     Mon Oct 23 08:43:55 2006 >>> app-office/openoffice-2.0.4

       merge time: 3 hours, 46 minutes and 44 seconds.

     Tue Nov  7 17:09:41 2006 >>> app-office/openoffice-2.0.4

       merge time: 2 hours, 44 minutes and 53 seconds.

$ emerge -vp openoffice

These are the packages that would be merged, in order:

Calculating dependencies ... done!

[ebuild   R   ] app-office/openoffice-2.0.4  USE="-binfilter branding cairo cups dbus -debug -eds firefox gnome gstreamer gtk java -kde -ldap -odk -pam -sound webdav" LINGUAS="-af -ar -be_BY -bg -bn -bs -ca -cs -cy -da -de -el en en_GB en_US -en_ZA -es -et -fa -fi fr -gu_IN -he -hi_IN -hr -hu -it -ja -km -ko -lt -mk -nb nl -nn -nr -ns -pa_IN -pl -pt -pt_BR -ru -rw -sh_YU -sk -sl -sr_CS -st -sv -sw_TZ -th -tn -tr -ts -vi -xh -zh_CN -zh_TW -zu" 0 kB 

$ equery s openoffice

[ Searching for packages matching openoffice... ]

* size of app-office/openoffice-2.0.4

           Total files : 4147

    Inaccessible files : 21

           Total size  : 300647.76 KiB
```

Que de l'ext2/3 !

Pour répondre à la question originale, /usr/portage, voire /usr/portage/distfiles sur des partitions séparées n'est pas une mauvaise idée du tout. Les deux en ext2, l'arbre avec des blocs de 1K, les sources avec des blocs de 4K (cf. Installation rapide de Gentoo Linux x86 avec raid logiciel.)

```
$ df -h|grep port

/dev/md/6             603M  248M  355M  42% /usr/portage

/dev/md/7             4.6G   93M  4.5G   3% /usr/portage/distfiles
```

----------

## titoucha

 *geekounet wrote:*   

>  *titoucha wrote:*   Je ne pensais pas qu'un fs pouvait avoir une pareil incidence sur une compilation, c'est vraiment impressionnant. 
> 
> En fait, c'est pas vraiment sur la compilation mais plutôt la décompression des archives et la suppression du répertoire de travail à la fin (4-5 Go).

 

C'est comme ça que je le concevais, je ne pensais pas qu'il y avait autant d'accès disque pour qu'il y ait une si grande différence.

Bon en plus tu as pris le plus gros morceau pour la compilation.   :Wink: 

@neysx, en quoi ce test est à la con, c'est clair que plusieurs paramètres entrent en ligne de compte, mais si le FS n'entre pas en ligne de compte alors comment expliques-tu une si grande différence.

----------

## blasserre

 *neysx wrote:*   

> [...] benchmarks à la con [...] Que de l'ext2/3 !
> 
> Pour répondre à la question originale, /usr/portage, voire /usr/portage/distfiles sur des partitions séparées n'est pas une mauvaise idée du tout. Les deux en ext2, l'arbre avec des blocs de 1K, les sources avec des blocs de 4K 

 

à ceci près que geekounet ne parlait pas de /usr/portage mais de /var/tmp/portage... et là effectivement entre xfs et autre chose, y'a pas photo

sinon, plutôt que de flammer gratuit, tu pourrais peut-être nous dire pourquoi c'est un bench à la con

----------

## geekounet

Et la différence ne s'est pas vérifiée que sur une compilation avec chacun :

```

     Thu May 11 14:28:47 2006 >>> app-office/openoffice-2.0.2-r2

       merge time: 7 hours, 36 minutes and 15 seconds.

     Tue Jul  4 10:22:57 2006 >>> app-office/openoffice-2.0.3

       merge time: 8 hours, 12 minutes and 34 seconds.

     Sat Aug 26 12:22:35 2006 >>> app-office/openoffice-2.0.3

       merge time: 8 hours, 5 minutes and 42 seconds.

     Sat Oct 14 06:56:43 2006 >>> app-office/openoffice-2.0.4

       merge time: 7 hours, 11 minutes and 52 seconds.

     Sun Nov  5 06:53:06 2006 >>> app-office/openoffice-2.0.4

       merge time: 5 hours, 22 minutes and 17 seconds.

     Tue Nov  7 04:39:05 2006 >>> app-office/openoffice-2.0.4

       merge time: 5 hours, 31 minutes and 20 seconds.
```

(j'ai dû le recompiler encore une fois suite à un revdep-rebuild ...  :Confused: )

A part le changement de FS, la machine était tout le temps dans les mêmes conditions, alors en quoi ça ne justifie pas la différence de perfs ?

----------

## nemo13

 *neysx wrote:*   

> C'est sûr qu'avec des benchmarks à la con comme ça,

 

Suffit-il d'avoir un "statut" de devell pour être mal poli ?

Daignerez-vous ,cher monsieur, étayer vos assertions ?

salutations.

----------

