En fait, c'est prévu pour qu'en cas de fs plein (pour un utilisateur), root aie encore une marge de manoeuvre pour réparer les dégats (avec comme effet secondaire la non-impactation immédiate des services qui tournent en root).
Le danger d'un disque plein c'est d'avoir une application critique se prendre une erreure du noyau lorsqu'elle doit écrire sur le disque. Par exemple une mise-à-jour du système qui foire à cause de cas. Jusqu'à présent, dpkg a toujours bien gèrer cette situation chez moi mais il ne faut pas trop compter sur le fait que l'application aie prévue ce cas de figure (car cet un problème qui peut devenir très complexe en fonction des application et je ne pense pas que linux offre toutes les fonctionnalité nécessaire à la prévention de ce genre d'erreures).
Note que modifier ce paramètre a juste l'effet de retarder la pleinitude du disque pour les applications lancées par un utilisateur, le risque de perdre des donnée est sans doutes plus important avec les applications utilisateurs (mal codées) qui n'arrivent plus a enregistrer leur état. Dans cette optique là (pour un /home par ex), on peut dire qu'il est plus sûr de baisser (voir de positionner à zéro) ce paramètre puisqu'il retarde la pleinitude du disque. Par contre, pour le / il est important que laisser ce paramètre à une valeur raisonnable, pour qu'un processus qui remplis le /tmp (s'il est sur la même partition) ne puisse pas affecter les services système.
En pratique, si tu fais attention, tu peux sans problème mettre ce paramètre à zéro. La vm du noyau arrivant plus ou moins bien à différer les écritures arrivant sur un disque plein en attendant qu'il se vide. D'ailleurs, je connais pas d'autre fs qui ont une option comparable. Les quotas et/ou la séparation des /tmp, /home et /var sur une autre partition que / sont quand même bien mieux adaptés pour se protéger contre ce genre de mésaventures.
[^] # Re: Histoire de calcul
Posté par benja . En réponse au message Lvm et taille des partitions. Évalué à 3.
Le danger d'un disque plein c'est d'avoir une application critique se prendre une erreure du noyau lorsqu'elle doit écrire sur le disque. Par exemple une mise-à-jour du système qui foire à cause de cas. Jusqu'à présent, dpkg a toujours bien gèrer cette situation chez moi mais il ne faut pas trop compter sur le fait que l'application aie prévue ce cas de figure (car cet un problème qui peut devenir très complexe en fonction des application et je ne pense pas que linux offre toutes les fonctionnalité nécessaire à la prévention de ce genre d'erreures).
Note que modifier ce paramètre a juste l'effet de retarder la pleinitude du disque pour les applications lancées par un utilisateur, le risque de perdre des donnée est sans doutes plus important avec les applications utilisateurs (mal codées) qui n'arrivent plus a enregistrer leur état. Dans cette optique là (pour un /home par ex), on peut dire qu'il est plus sûr de baisser (voir de positionner à zéro) ce paramètre puisqu'il retarde la pleinitude du disque. Par contre, pour le / il est important que laisser ce paramètre à une valeur raisonnable, pour qu'un processus qui remplis le /tmp (s'il est sur la même partition) ne puisse pas affecter les services système.
En pratique, si tu fais attention, tu peux sans problème mettre ce paramètre à zéro. La vm du noyau arrivant plus ou moins bien à différer les écritures arrivant sur un disque plein en attendant qu'il se vide. D'ailleurs, je connais pas d'autre fs qui ont une option comparable. Les quotas et/ou la séparation des /tmp, /home et /var sur une autre partition que / sont quand même bien mieux adaptés pour se protéger contre ce genre de mésaventures.