Selon Cyril Chaboisseau <[email protected]>: > * Christophe Courtois <[email protected]> [2009-09-22 21:38 +0200]: > > > > régulièrement je me fait avoir en ne donnant pas suffisemment > > > d'espace /usr /var > > > > Personnellement, je ne me casse plus le crâne et mon manque chronique de > > temps me force à aller au plus simple et au moins casse-tête : 1 partition > de > > tout le disque. > > Ça va faire hurler les puristes, et sur un serveur au boulot je ne ferais > pas > > ça. Tous les 3 ans je claque 100 ¤ en disque dur pour gérer l'emboupoint > des > > données. Point. > > sur le principe et en théorie tu as raison d'autant plus que le To > (1500Go pour être précis) coûte moins de 90¤ > > mais dans la pratique, cette approche a qques inconvénients en plus > d'être risquée : > > tu n'as pas la souplesse de pouvoir monter les partitions avec des > options différentes (noatime, ro) ou FS différents (ext4) > > et tu n'es pas à l'abri d'un FS qui part en vrille à cause d'un bug > noyau ou dysfonctionnement matériel (auquel cas ça limite les dégâts) ou > bien d'un programmes/service/malware/personne mal intentionnée qui va > remplir le FS en question (fichier de log par ex.) et donc plomber tout > le système alors qu'en compartimentant un peu certains points de montage > (/tmp, /home, /var...) tu ne bloquera que l'écriture de nouveaux log (si > /var ou /var/log) ou bien les processus qui ont besoin d'écrire sur la > partition en question > > > donc si c'est pour un portable à usage perso ou sur une machine qui ne > fait pas tourner grand chose, ok pas de soucis mais pour un serveur qui > accueille éventuellement des utilisateurs ou fait tourner des services, > là je dis ATTENTION aux DoS (Denial of Service) > -> c'est si facile de saturer un log de mail/web ou d'avoir un script > qui remplisse des formulaire en y mettant des tonnes d'infos > > à l'inverse, en taillant les FS au double (voire triple si on a trop de > d'espace disque à gâcher) de ce que l'on pense être suffisant, je trouve > ça vraiment intéressant de voir si un jour cette estimation est dépassé > ce qui permet justement d'aller fouiller dans le FS (et donc rép.) en > question là où ça pêche ! > alors qu'avec ton approche tu mets tout dans le même panier et tu ne > vois pas arriver les remplissages suspects de log ou de base de données > par ex. > > -- > Cyril Chaboisseau >
bonjour, concernant le /var il existe 2 sous répertoires qui enflent : le répertoire des journaux d'activité (logs) le répertoire d'indexation des paquets ( /var/lib/apt/ ) et d'autres répertoires qui enflent avec le temps ... comment limiter la casse et de raletir le processus, l'idée consisterai à supprimer certains fichiers trop anciens serait ce trop imprudent ? slt bernard
