Disque dur plein : risques ? limites ? solutions ?

YannUbuntu · Le 23/07/2010, à 06:46

Votre idée d'optimiser les 5% d'espace root selon la taille des partitions me parait bonne, NooP ou Vysserk3 on compte sur l'un de vous pour la proposer aux devs de tune2fs ? Merci d'avance pour votre aide.

Tout le monde est ok sur l'idée d'améliorer, dans un 1er temps, les messages d'avertissement de gnome-disk-utility/gdu-notification-daemon comme ci-dessous ?

1) afficher les fenêtres classiques (cf post#2) tant qu'il reste au moins y% d'espace libre
2) si x%<espace libre<y% : afficher un message "Si vous ne libérez pas d'espace sur votre disque, vos applications risquent de ne pas fonctionner correctement"
3) si espace libre<x% : afficher un message "Attention ! Si vous ne libérez pas d'espace sur votre disque, votre système risque de ne plus pouvoir démarrer ou fonctionner correctement".

Si oui, je vais faire un rapport de bug.

A noter aussi que les messages d'avertissements sont inutiles si l'utilisateur n'est pas devant son PC pendant que son disque se remplit (ce qui peut arriver par exemple lors d'opérations "longues" de type téléchargement, rip de DVD, etc).

Pour pouvoir se logguer graphiquement en non-root, voici quelques idées auxquelles je pense :
(1) a mon avis la solution "idéale" serait de permettre aux administrateurs Ubuntu (les utilisateurs qui ont les droits sudo) d'accéder à l'espace réservé à root (en modifiant les propriétés de l'espace réservé root, ou peut-être en modifiant les propriétés de sudo ... ). Mais, même si c'était possible, ca ne serait applicable qu'aux partitions qui ont cet espace réservé root (ext2/3/4 uniquement?).
(2) lorsque le disque est quasi-plein, on pourrait proposer la création d'un compte root de façon a pouvoir booter sur ce compte root lorsque le disque est plein. Idem, valable uniquement pour du ext2/3/4.
(3) d'après le post #45 de NooP, il faudrait de l'espace "non-root" dans /tmp, /home/user, /var/log, /var/temp. Sachant que ces dossiers peuvent se trouver sur des partitions séparées, le plus simple serait peut-être de réserver l'espace de la même façon que l'espace réservé pour "root" (c'est-a-dire actuellement 5% sur toutes les partitions). Si root peut écrire sur cet espace non-root réservé, les 5% d'espace root deviennent inutiles, il est surement possible de les désactiver via tune2fs. Et il y a peut-être moyen de faire en sorte que cette réservation d'espace non-root (si non liée a tune2fs) soit valable sur tous types de partitions.
(4) lorsque le disque est quasi-plein, suspendre les opérations non-vitales qui remplissent le disque (installation de nouveaux logiciels via la Logithèque, suspendre les téléchargements en cours, rip, etc..). Valable sur tous types de partitions.

Qu'en pensez-vous ?

Vysserk3 · Le 23/07/2010, à 09:43

YannUbuntu a écrit :

Votre idée d'optimiser les 5% d'espace root selon la taille des partitions me parait bonne, NooP ou Vysserk3 on compte sur l'un de vous pour la proposer aux devs de tune2fs ? Merci d'avance pour votre aide.
Tout le monde est ok sur l'idée d'améliorer, dans un 1er temps, les messages d'avertissement de gnome-disk-utility/gdu-notification-daemon comme ci-dessous ?
1) afficher les fenêtres classiques (cf post#2) tant qu'il reste au moins y% d'espace libre
2) si x%<espace libre<y% : afficher un message "Si vous ne libérez pas d'espace sur votre disque, vos applications risquent de ne pas fonctionner correctement"
3) si espace libre<x% : afficher un message "Attention ! Si vous ne libérez pas d'espace sur votre disque, votre système risque de ne plus pouvoir démarrer ou fonctionner correctement".
Si oui, je vais faire un rapport de bug.
A noter aussi que les messages d'avertissements sont inutiles si l'utilisateur n'est pas devant son PC pendant que son disque se remplit (ce qui peut arriver par exemple lors d'opérations "longues" de type téléchargement, rip de DVD, etc).
Pour pouvoir se logguer graphiquement en non-root, voici quelques idées auxquelles je pense :
(1) a mon avis la solution "idéale" serait de permettre aux administrateurs Ubuntu (les utilisateurs qui ont les droits sudo) d'accéder à l'espace réservé à root (en modifiant les propriétés de l'espace réservé root, ou peut-être en modifiant les propriétés de sudo ... ). Mais, même si c'était possible, ca ne serait applicable qu'aux partitions qui ont cet espace réservé root (ext2/3/4 uniquement?).
(2) lorsque le disque est quasi-plein, on pourrait proposer la création d'un compte root de façon a pouvoir booter sur ce compte root lorsque le disque est plein. Idem, valable uniquement pour du ext2/3/4.
(3) d'après le post #45 de NooP, il faudrait de l'espace "non-root" dans /tmp, /home/user, /var/log, /var/temp. Sachant que ces dossiers peuvent se trouver sur des partitions séparées, le plus simple serait peut-être de réserver l'espace de la même façon que l'espace réservé pour "root" (c'est-a-dire actuellement 5% sur toutes les partitions). Si root peut écrire sur cet espace non-root réservé, les 5% d'espace root deviennent inutiles, il est surement possible de les désactiver via tune2fs. Et il y a peut-être moyen de faire en sorte que cette réservation d'espace non-root (si non liée a tune2fs) soit valable sur tous types de partitions.
(4) lorsque le disque est quasi-plein, suspendre les opérations non-vitales qui remplissent le disque (installation de nouveaux logiciels via la Logithèque, suspendre les téléchargements en cours, rip, etc..). Valable sur tous types de partitions.
Qu'en pensez-vous ?

Appelle plutôt ça une demande de nouvelles fonctionnalités (wishlist) plutôt que rapport de bug (de toute façon ce sera trié à un moment donné donc autant bien le faire dés le début).
Concernant tune2fs, j'ai regardé vite fait le code C du truc, apparemment ce serait assez simple à faire, juste à remplacer ce qu'ils font actuellement (ou plutôt rajouter une option à tune2fs, genre -m auto ou un truc dans le genre, car il faut toujours laisser l'existant ne serait-ce que pour des raisons de compatibilités) :

sb->s_r_blocks_count = (unsigned int) (reserved_ratio *sb->s_blocks_count / 100.0);

où s_r_blocks_count représente le nombre total de blocs que l'on veut réserver
reserved_ratio le pourcentage compris entre 0 et 50 que l'utilisateur passe en paramètre
s_blocks_count le nombre total de blocs du systèmes de fichiers
par

sb->s_r_blocks_count = (unsigned int)  une_fonction_qui_va_bien(sb->s_blocks_count);

où une_fonction_qui_va_bien en fonction du nombre total de blocs (proportionnelle à la taille du système de fichiers) va sortir une réservation raisonnable (cf grille de NooP).

Sinon :

(1) et bien, c'est déjà le cas si l'utilisateur peut utiliser sudo pour s'accorder des droits root temporairement, alors il peut accéder à cette espace...moyennant la demande de mot de passe naturellement, mais attention au risque de sécurité. Si l'utilisateur a un script malicieux qui remplit sa partition et qu'on lui permet de le faire en root, alors il risque de planter tout le système, d'où un potentiel risque de failles. Il est très important de garder se cloisonnement et de ne pas permettre à l'utilisateur de casser des choses en dehors de son dossier personnel.

(2) lorsque le disque est quasi plein, il est temps de prendre des mesures humaines non ? Il est temps de corriger les causes plutôt que les conséquences

(3) utiliser /tmp exclusivement en secours pourquoi pas, mais encore une fois, ne pas néglier les risques de sécurité

(4) non, ce genre de trucs n'est pas souhaitable, ce n'est pas au système de décider quoi arrêter et tout ça, ce serait trop compliqué à mettre en œuvre et source d'indéterminismes. De plus si les applications sont bien conçues, elles doivent prendre en compte le cas où la partition est pleine (ce qui est le cas avec apt-get par exemple). Il ne s'agit pas de créer un surveillant qui dira que telle application doit se fermer à tel moment.

YannUbuntu · Le 23/07/2010, à 10:30

Vysserk3 a écrit :

(1) et bien, c'est déjà le cas si l'utilisateur peut utiliser sudo pour s'accorder des droits root temporairement, alors il peut accéder à cette espace...

A priori actuellement non, ca bloque même pour les utilisateurs non-root qui ont les "droits sudo" (entre autres le 1er utilisateur créé sur Ubuntu) et qui donnent le mot-de-passe sudo lors de la connexion, quelqu'un confirme ? (Brunod?)

Après réflexion l'idée 1 n'est pas si "idéale" que ca car les utilisateurs sans droits sudo seraient bloqués tout pareil. Sur ce point, c'est mieux que la 2 (seul root n'est pas bloqué), mais moins bien que 3 et 4.

Vysserk3 · Le 23/07/2010, à 10:40

Un autre point dont on a pas parlé, c'est la fragmentation. A priori le taux de fragmentation restent assez faible avec les partitions ext...pour peu qu'on ne remplisse pas trop le disque...C'est peut être la cause aussi de certains problèmes rencontrés par les utilisateurs

NooP · Le 23/07/2010, à 11:40

YannUbuntu a écrit :

(1) a mon avis la solution "idéale" serait de permettre aux administrateurs Ubuntu (les utilisateurs qui ont les droits sudo) d'accéder à l'espace réservé à root (en modifiant les propriétés de l'espace réservé root, ou peut-être en modifiant les propriétés de sudo ... ). Mais, même si c'était possible, ca ne serait applicable qu'aux partitions qui ont cet espace réservé root (ext2/3/4 uniquement?).
(2) lorsque le disque est quasi-plein, on pourrait proposer la création d'un compte root de façon a pouvoir booter sur ce compte root lorsque le disque est plein. Idem, valable uniquement pour du ext2/3/4.
(3) d'après le post #45 de NooP, il faudrait de l'espace "non-root" dans /tmp, /home/user, /var/log, /var/temp. Sachant que ces dossiers peuvent se trouver sur des partitions séparées, le plus simple serait peut-être de réserver l'espace de la même façon que l'espace réservé pour "root" (c'est-a-dire actuellement 5% sur toutes les partitions). Si root peut écrire sur cet espace non-root réservé, les 5% d'espace root deviennent inutiles, il est surement possible de les désactiver via tune2fs. Et il y a peut-être moyen de faire en sorte que cette réservation d'espace non-root (si non liée a tune2fs) soit valable sur tous types de partitions.
(4) lorsque le disque est quasi-plein, suspendre les opérations non-vitales qui remplissent le disque (installation de nouveaux logiciels via la Logithèque, suspendre les téléchargements en cours, rip, etc..). Valable sur tous types de partitions.
Qu'en pensez-vous ?

1) Cela ne changerait rien, car pour lancer le programme qui testerais si l'utilisateur est un SUDO, il faut d'abord que celui ci se connecte. Or, dans le cas présent, il ne peux pas. Permettre à cet utilisateur SUDO d'utiliser l'espace réservé à root, cela reviens à l'autoriser à remplir le disque à 100%. Le serpent se mord la queue.

2) Sécurité ? Si le disque est plein, tu vas avoir une boite qui te demandera le mot de passe à attribuer à root. Ce qui fait que n'importe qui se trouvant devant la machine à ce moment se retrouve propulsé root.

3) Les partition /tmp, /var etc sont en installation par défaut toutes dans la partition /. Ce qui fait que si tu remplis le /home, tu n'aurais de toute façons plus de place sur /tmp etc ... De plus, réserver de l'espace non-root, cela reviens à dire que l'utilisateur peux s'en servir. Il aura donc le droit de remplir le disque à 100%, et non à seulement 95% comme précédemment, bloquant de ce fait toute intervention de la part de root puisque celui ci voit son espace réservé partagé avec des utilisateurs.

4) Irréalisable. Comment savoir QUOI stopper ? Imagine que tu sois entrain de réaliser un calcul, qui n'utilise pas le disque, et qui tourne depuis 2 mois, et qui de plus stockerais ses résultats sur un disque réseau. Ton demon risque de stopper cette tâche. Simplement irréaliste.

Seul l'utilisateur est capable de gérer son espace disque. C'est simplement un problème d'éducation. Si on fait l'analogie avec la voiture (Je vais me prendre mon point Jacky) :

Tu as le plein d'essence. Au fur à mesure, tu en consommes. A un certain niveau, le voyant de réserve s'allume (Ce sont les alertes d'espace disque qui existent déjà). Si l'utilisateur ne fais pas le plein (Entendre par la fait un peu de ménage dans ses données), que déciderais tu niveau voiture ?

Stopper le moteur ?
Faire descendre les passagers + bagages pour consommer moins ?
Ouvrir une trappe avec un double des clefs afin que le premier venu puisse aller à la station (Et par la même occasion se barrer avec ta voiture ?)
Créer une seconde réserve (Que de toute façon l'utilisateur épuisera comme la première) ?

Ou alors, ne faut-il tout simplement pas laisser faire, en pensant : Si tu ne fais rien, tu seras en panne.

Dernière modification par NooP (Le 23/07/2010, à 12:30)

marcodel · Le 23/07/2010, à 12:11

salut
une hypothese
en cas de non demarrage , a cause d'un disque plein
vue qu'il reste de la place reserve pour root ( 5% )
ne serait'il pas possible de demarrer en recovery ( donc en root ) et de lancer l'interface graphique par startx pour faire le menage ?
a+

NooP · Le 23/07/2010, à 12:18

Et du coups, propulser l'utilisateur devant le clavier comme ROOT, parce qu'un autre utilisateur à remplis le disque ?

Que feraient la plupart des gens ? Crois tu qu'il supprimeraient leurs 200 fichiers tabatakashapwal.avi de 5mo chacuns dans leur répertoire, où le fichier ubuntu-10.10.dvd.iso de 4Go dans celui du voisin ? Parce que supprimer les fichiers du voisin, cela veut dire conserver tous les siens.

Il ne faut pas perdre de vue que Linux est un système multi utilisateurs, et que de ce fait, on ne peux gérer un soucis comme si c'était un système mono utilisateur.

Dernière modification par NooP (Le 23/07/2010, à 12:26)

marcodel · Le 23/07/2010, à 12:26

re

Il ne faut pas perdre de vue que Linux est un système multi utilisateurs, et que de ce fait, on ne peux gérer un soucis comme si c'était un système mono utilisateur.

certe , mais cela n'empeche pas d'avoir un admin du dit ordi , qui prend les decisions extreme
surtout sur un ordi multi-utilisateurs
a+

Dernière modification par marcodel (Le 23/07/2010, à 12:27)

NooP · Le 23/07/2010, à 12:40

La seule solution viable et simple serait :

1) Que tous les utilisateurs créés sur Ubuntu fassent partie d'un même groupe (quota ?).
2) Appliquer des quotas à ce groupe (Soft : 85% du disque, Hard : 92%).
3) Lors du démarrage de la session, un test est fait pour savoir si le quotas Soft est dépassé, et dans ce cas, message d'avertissement à l'utilisateur connecté.

Dernière modification par NooP (Le 23/07/2010, à 12:44)

draco31.fr · Le 23/07/2010, à 12:49

Vysserk3 a écrit :

Un autre point dont on a pas parlé, c'est la fragmentation. A priori le taux de fragmentation restent assez faible avec les partitions ext...pour peu qu'on ne remplisse pas trop le disque...C'est peut être la cause aussi de certains problèmes rencontrés par les utilisateurs

Intéressante ta remarque, c'est LE problème que je rencontre actuellement ... mais pas parce que mon disque est plein !
Tout dépend de comment les fichiers évoluent. Sur un système où les fichiers "grossissent" petit à petit, la fragmentation est inévitable. Le système de fichier ne peut que prévoir une place contigüe pour qq extents, mais si le fichier prend plus d'extents que prévus, il se fragmente !

Pour en revenir au problème de l'espace disque.
Il y une option -r dans tune2fs pour indiquer un nombre de bloc (ce qui revient à préciser un taille fixe).
Donc pas besoin de dev.
Par ailleurs, je ne pense pas que le "problème" soit au niveau de tune2fs. Ces outils sont appelés par l'installateur ou les interfaces graphiques (gparted) pour manipuler les partitions et les systèmes de fichiers. Ce sont les options utilisées par défaut par ces interfaces qui posent problèmes.
De plus, l'option -u permet de définir l'utilisateur qui pourra utiliser l'espace réservé. Rien n'empêche que ce soit celui de l'administrateur de la machine pour qu'il se log en graphique.
Enfin, si GDM ou KDM se lancent en root, il doit suffir de démarrer une session xterm pour nettoyer le bousin.

Une autre solution, serait de démarrer la session dans un équivalent "read-only".
L'idée : si on approche la limite sous laquelle il n'y a plus assez d'espace libre pour maintenir ou lancer une session graphique, on averti l'utilisateur que l'on bloque toutes nouvelles écritures sur le disque, sauf suppression de fichiers.

Il ne faut pas non plus négliger la possibilité de "stocker" les fichiers pour la session graphique en RAM/swap.
Puisque la plupart de ces fichiers sont volatiles, et qu'on peut se passer des logs momentanément, autant faire avec la RAM !
En fait, je me rappelle avoir eu des soucis avec mon disque, après démarrage de la session. Ce dernier passait en read-only (message mount -ro dans dmesg) suite à des erreurs. La session fonctionnait toujours, je pouvais consulter les logs, etc. Cependant, rien de ce que je faisais n'était conservé au reboot suivant. Bref, ça ressemblait beaucoup à une session Live sauf que c'était bien ma session sur disque dur !! Je ne sais pas où étaient stocké les nouveaux fichiers de la session (socket, /tmp ...).

D'ailleurs, je me demande comment ça fonctionne pour les LiveUSB persistant. Quel est l'espace conservé ? Est-ce que /tmp et /var/log sont dans le fichier casper et /home à part ?

Brunod · Le 23/07/2010, à 15:09

YannUbuntu a écrit :

Vysserk3 a écrit :
(1) et bien, c'est déjà le cas si l'utilisateur peut utiliser sudo pour s'accorder des droits root temporairement, alors il peut accéder à cette espace...
A priori actuellement non, ca bloque même pour les utilisateurs non-root qui ont les "droits sudo" (entre autres le 1er utilisateur créé sur Ubuntu) et qui donnent le mot-de-passe sudo lors de la connexion, quelqu'un confirme ? (Brunod?)
Après réflexion l'idée 1 n'est pas si "idéale" que ca car les utilisateurs sans droits sudo seraient bloqués tout pareil. Sur ce point, c'est mieux que la 2 (seul root n'est pas bloqué), mais moins bien que 3 et 4.

Je ne puis confirmer ou infirmer : à l'époque, j'avais repris la main et fait le ménage avec un livecd. Je n'avais pas cheché plus loin puisque je n'avais pas compris de suite d'où ça venait. Alors j'avais commencé à déplacer mes données vers un autre support pensant le système fondamentalement planté, puis l'ayant vidé un peu, j'ai réessayé je ne sais plus pourquoi de redémarrer et ça a fonctionné jusqu'au "trop plein" suivant.
Sinon la saturation était venue en douce par un téléchargement torrent avec azureeus sur un petit disque système de 40Go.

YannUbuntu · Le 26/07/2010, à 08:56

Vysserk3 a écrit :

si les applications sont bien conçues, elles doivent prendre en compte le cas où la partition est pleine.

Oui ca serait l'idéal. Mais :
- si plusieurs de ces applications remplissent la partition simultanément, une vérification avant de démarrer l'opération est insuffisant, il faudrait que chaque appli vérifie régulièrement le % de remplissage de la partition. Ca utiliserait plus de ressources qu'un seul démon du système.
- et surtout, même si Canonical arrivait a l'imposer aux applis de ses dépôts officiels, pour les appli non-officielles c'est impossible, et le risque resterait entier pour le système.

Vysserk3 a écrit :

A priori le taux de fragmentation restent assez faible avec les partitions ext...pour peu qu'on ne remplisse pas trop le disque...

La SWAP ne permet-elle pas de defragmenter ? Raison de plus pour avoir un espace "reservé non-root" ?

NooP a écrit :

1) Cela ne changerait rien, car pour lancer le programme qui testerais si l'utilisateur est un SUDO, il faut d'abord que celui ci se connecte. Or, dans le cas présent, il ne peux pas.

?? GDM devrait pouvoir consulter la table des droits utilisateurs pour savoir qui est sudo ou pas, non ?

NooP a écrit :

Permettre à cet utilisateur SUDO d'utiliser l'espace réservé à root, cela reviens à l'autoriser à remplir le disque à 100%.

idem actuellement avec root: il peut remplir son disque a 100%. Comme sur Ubuntu l'admin n'est pas root mais sudo, l'idée c'est de remplacer l'espace "réservé root" (actuellement inutile sur Ubuntu car comme tu l'as indiqué quelques posts plus haut, il n'est pas possible de créer l'utilisateur root si le disque est plein) par un espace "réservé sudo".
Chose qui est peut-être possible via l'option -u indiquée par draco:

draco31.fr a écrit :

l'option -u permet de définir l'utilisateur qui pourra utiliser l'espace réservé. Rien n'empêche que ce soit celui de l'administrateur de la machine pour qu'il se log en graphique.

NooP a écrit :

2) Sécurité ? Si le disque est plein, tu vas avoir une boite qui te demandera le mot de passe à attribuer à root. Ce qui fait que n'importe qui se trouvant devant la machine à ce moment se retrouve propulsé root.

Non, la "boite" demanderait évidemment le mot de passe sudo pour créer le compte root. (comme actuellement quand tu veux activer le compte root il faut sudo). Si l'utilisateur n'a pas les droits sudo, on pourrait par exemple passer en mode "lecture seule" (cf message de draco) ou bien idée 4 (liste d'applications bloquées).

NooP a écrit :

3) Les partition /tmp, /var etc sont en installation par défaut toutes dans la partition /. Ce qui fait que si tu remplis le /home, tu n'aurais de toute façons plus de place sur /tmp etc ...

?? Idem avec l'espace réservé root actuellement.

NooP a écrit :

4) Irréalisable. Comment savoir QUOI stopper ? Imagine que tu sois entrain de réaliser un calcul, qui n'utilise pas le disque, et qui tourne depuis 2 mois, et qui de plus stockerais ses résultats sur un disque réseau. Ton demon risque de stopper cette tâche. Simplement irréaliste.

Pas d'accord. D'une part l'idée 4 c'est de faire une liste d'opérations "à bloquer" par le demon, donc si le programme de calcul n'est pas "à bloquer", il continuera. D'autre part cette liste pourrait être personnalisable.

NooP a écrit :

La seule solution viable et simple serait :
1) Que tous les utilisateurs créés sur Ubuntu fassent partie d'un même groupe (quota ?).
2) Appliquer des quotas à ce groupe (Soft : 85% du disque, Hard : 92%).
3) Lors du démarrage de la session, un test est fait pour savoir si le quotas Soft est dépassé, et dans ce cas, message d'avertissement à l'utilisateur connecté.

Je n'ai pas compris la différence avec les messages d'avertissement actuels.

draco31.fr a écrit :

Enfin, si GDM ou KDM se lancent en root, il doit suffir de démarrer une session xterm pour nettoyer le bousin.

?? (pas compris)

draco31.fr a écrit :

Une autre solution, serait de démarrer la session dans un équivalent "read-only".
L'idée : si on approche la limite sous laquelle il n'y a plus assez d'espace libre pour maintenir ou lancer une session graphique, on averti l'utilisateur que l'on bloque toutes nouvelles écritures sur le disque, sauf suppression de fichiers.

intéressant. Ca me parait dans la continuité de l'idée 4 (qui fait une liste d'opérations "interdites"), mais en plus restrictif vu que là il s'agirait de faire une liste d'opérations "autorisées".

draco31.fr a écrit :

Il ne faut pas non plus négliger la possibilité de "stocker" les fichiers pour la session graphique en RAM/swap.

Pour la RAM ton expérience montre que Ubuntu sait l'utiliser pour le démarrage si besoin.

Pour la SWAP il faudrait le vérifier auprès des devs, mais ca me paraitrait logique. D'ailleurs finalement l'espace "réservé non-root" je le vois un peu comme de la SWAP (on n'y met que des fichiers temporaires) sauf que ca n'est pas sur une partition type SWAP, mais dispatché sur toutes les partitions. On pourrait aussi le vérifier nous-mêmes : si un utilisateur a une SWAP surdimensionnée mais qu'il ne peut pas se logguer avec un disque plein, c'est que la SWAP n'est pas utilisée pour le démarrage.

@Brunod : avais-tu beaucoup de SWAP ?

draco31.fr a écrit :

je me demande comment ça fonctionne pour les LiveUSB persistant. Quel est l'espace conservé ? Est-ce que /tmp et /var/log sont dans le fichier casper et /home à part ?

il faudrait poser la question aux experts (frafra, smo...)

Vysserk3 · Le 26/07/2010, à 09:38

YannUbuntu a écrit :

Vysserk3 a écrit :
si les applications sont bien conçues, elles doivent prendre en compte le cas où la partition est pleine.
Oui ca serait l'idéal. Mais :
- si plusieurs de ces applications remplissent la partition simultanément, une vérification avant de démarrer l'opération est insuffisant, il faudrait que chaque appli vérifie régulièrement le % de remplissage de la partition. Ca utiliserait plus de ressources qu'un seul démon du système.
- et surtout, même si Canonical arrivait a l'imposer aux applis de ses dépôts officiels, pour les appli non-officielles c'est impossible, et le risque resterait entier pour le système.

En fait, quand je parle d'applications, je parle en fait de ce qu'elles utilisent toutes en commun pour écrire et lire sur le disque, à savoir les primitives write, read (entre autres) fournies par le système, pour éviter de devoir réinventer la roue. Et justement avec les quotas, ceci permet d'être unifié, les quotas se situant à un niveau plus bas, n'importe quelle application qui voudra écrire ne pourra pas s'il n'y a pas assez de quota. Donc l'histoire de ton démon système, c'est déjà le cas, vu que chaque programme qui voudra écrire utilisera derrière les mêmes fonctions d'écriture/lecture qui elles même seront limitées par les quotas...

YannUbuntu a écrit :

Vysserk3 a écrit :
A priori le taux de fragmentation restent assez faible avec les partitions ext...pour peu qu'on ne remplisse pas trop le disque...
La SWAP ne permet-elle pas de defragmenter ? Raison de plus pour avoir un espace "reservé non-root" ?

Non, la SWAP n'a rien à voir avec ça, elle permet de pallier un manque de mémoire vive en utilisant le disque comme stockage. Elle est aussi utilisée pour l'hibernation.

YannUbuntu a écrit :

NooP a écrit :
Permettre à cet utilisateur SUDO d'utiliser l'espace réservé à root, cela reviens à l'autoriser à remplir le disque à 100%.
idem actuellement avec root: il peut remplir son disque a 100%. Comme sur Ubuntu l'admin n'est pas root mais sudo, l'idée c'est de remplacer l'espace "réservé root" (actuellement inutile sur Ubuntu car comme tu l'as indiqué quelques posts plus haut, il n'est pas possible de créer l'utilisateur root si le disque est plein) par un espace "réservé sudo".
Chose qui est peut-être possible via l'option -u indiquée par draco:

Sauf que pour remplir le disque l'utilisateur doit faire sudo devant une commande de remplissage ou passer en root. A priori, personne ne devrait lancer ses programmes genre P2P, traitement vidéo avec sudo ou en root (une des raisons pour lesquelles le compte root a été désactivé, c'est de limiter ce genre de truc). Donc en simple utilisateur, il ne pourra rien remplir du tout. Après évidemment, s'il le fait exprès, il n'y a rien à faire, on pourra toujours trouver un chemin qui fait que l'utilisateur fait n'importe quoi.

YannUbuntu a écrit :

NooP a écrit :
4) Irréalisable. Comment savoir QUOI stopper ? Imagine que tu sois entrain de réaliser un calcul, qui n'utilise pas le disque, et qui tourne depuis 2 mois, et qui de plus stockerais ses résultats sur un disque réseau. Ton demon risque de stopper cette tâche. Simplement irréaliste.
Pas d'accord. D'une part l'idée 4 c'est de faire une liste d'opérations "à bloquer" par le demon, donc si le programme de calcul n'est pas "à bloquer", il continuera. D'autre part cette liste pourrait être personnalisable.

Ce que tu veux faire existe déjà, ce sont les quotas comme je le disais au dessus

YannUbuntu a écrit :

NooP a écrit :
La seule solution viable et simple serait :
1) Que tous les utilisateurs créés sur Ubuntu fassent partie d'un même groupe (quota ?).
2) Appliquer des quotas à ce groupe (Soft : 85% du disque, Hard : 92%).
3) Lors du démarrage de la session, un test est fait pour savoir si le quotas Soft est dépassé, et dans ce cas, message d'avertissement à l'utilisateur connecté.
Je n'ai pas compris la différence avec les messages d'avertissement actuels.

La différence avec les quotas, c'est que non seulement on aura les messages d'avertissement, mais en plus l'utilisateur ne pourra pas quoi qu'il fasse dépasser ce quota ce qui règle le problème initial.

YannUbuntu a écrit :

draco31.fr a écrit :
Enfin, si GDM ou KDM se lancent en root, il doit suffir de démarrer une session xterm pour nettoyer le bousin.
?? (pas compris)

Il parle de la session xterm de secours proposée dans les options de gdm pour pouvoir démarrer sur une console afin de prendre la main sur un système endommagé mais on sort du cadre on l'on voulait que ce soit fait en graphique par l'utilisateur simple. Mais le simple utilisateur devrait déjà apprendre à ne pas remplir avant d'apprendre une éventuelle méthode graphique pour réparer (traiter les causes plutôt que les conséquences)

YannUbuntu · Le 26/07/2010, à 10:37

Merci pour tes explications.

Vysserk3 a écrit :

A priori, personne ne devrait lancer ses programmes genre P2P, traitement vidéo avec sudo ou en root

Complètement d'accord. Je ne prends pas ce cas en compte.

Vysserk3 a écrit :

Ce que tu veux faire existe déjà, ce sont les quotas comme je le disais au dessus

Impeccable. Savez-vous ou l'on peut trouver de la doc à ce sujet ?

Vysserk3 a écrit :

chaque programme qui voudra écrire utilisera derrière les mêmes fonctions d'écriture/lecture qui elles même seront limitées par les quotas

Si j'ai bien compris ca équivaut donc à la solution "lecture seule" proposée par draco ?

NooP a écrit :

La seule solution viable et simple serait :
1) Que tous les utilisateurs créés sur Ubuntu fassent partie d'un même groupe (quota ?).
2) Appliquer des quotas à ce groupe (Soft : 85% du disque, Hard : 92%).
3) Lors du démarrage de la session, un test est fait pour savoir si le quotas Soft est dépassé, et dans ce cas, message d'avertissement à l'utilisateur connecté.

C'est bien du même système de quotas (quotas sur primitives write, read, ...) dont tu parles ?
Si oui, cela signifie qu'on peut attribuer des quotas différents aux primitives selon le groupe d'utilisateur ?
Que signifient les quotas "soft" et "hard" ?

Vysserk3 · Le 26/07/2010, à 10:44

Ce n'est pas vraiment en read-only vu qu'un utilisateur avec plus de quota pourra écrire un peu plus longtemps sur la partition. Donc c'est beaucoup plus fin que le tout ou rien.
Il y a une page de doc http://doc.ubuntu-fr.org/utilisateurs/mulx/quota
Et beaucoup sur le web aussi. C'est une solution éprouvée qui existe depuis longtemps. Il peut y avoir des quotas par utilisateur et par groupe naturellement.

YannUbuntu · Le 26/07/2010, à 11:25

Merci. Ca me fera de la lecture pour les vacances

Brunod · Le 26/07/2010, à 17:03

YannUbuntu a écrit :

@Brunod : avais-tu beaucoup de SWAP ?

Rien de spécial , ce qui était proposé à l'install en l'occurence entre 2 et 4 Go

YannUbuntu · Le 27/07/2010, à 04:01

Pour info je viens de faire un test :
- avec 50Mo de libres sur DD je peux booter sur GNOME / KDE, mais quelques composants crashent
- avec 200Ko de libres sur DD, impossible de booter ni sur Gnome, ni sur Kde, ni sur Lubuntu, ni sur Openbox, ni sur "Session de secours Gnome". Par contre j'ai pu booter sur la session xterm.

YannUbuntu · Le 28/08/2010, à 06:33

Bonjour
j'ai créé un rapport de bug et mis le lien dans le post #1, mais oublié d'en parler ici. Le voici : https://bugs.launchpad.net/gdm/+bug/610358

N'hésitez pas à commenter/voter ("This bug affects me too")

Hoper · Le 28/08/2010, à 07:15

Pff.... on se croirait sous windows... Le pire étant le message "Votre ordinateur pourrait ne pas bien fonctioner si il ne reste plus assez d'espace". Alors la c'est sur que l'utilisateur est super avancé. Toujours tout faire pour que le type qui n'y connais rien ne puisse surtout pas s'améliorer hein ?

Si vraiment tu tiens à ton avertissement, alors le seul truc valable c'est :

"Le processus bidule à besoin, lors de son lancement, d'écrire un fichier dans /tmp. Donc si / et /home ne sont pas deux systèmes de fichiers différent, et que vous remplissez donc le / à 100%, ce processus, et l'interface graphique donc, ne pourront pas etre lancés au démarrage."

YannUbuntu · Le 28/08/2010, à 07:38

Merci pour le ton agressif... Rien n'empêche d'avoir un message d'alerte plus détaillé, j'ajoute la remarque dans le rapport de bug.

Hoper · Le 29/08/2010, à 18:23

Désolé pour le ton, mais il y a franchement des trucs plus important à faire que de vouloir réfléchir à la place des gens.

YannUbuntu · Le 30/08/2010, à 06:06

C'est ton avis, et tu n'es pas obligé de suivre cette discussion si tu as plus important à faire.

Perso je trouve que ce bug est suffisamment grave pour que j'y consacre du temps.

Airballman · Le 30/08/2010, à 08:03

YannUbuntu a écrit :

C'est ton avis, et tu n'es pas obligé de suivre cette discussion si tu as plus important à faire.
Perso je trouve que ce bug est suffisamment grave pour que j'y consacre du temps.

+1
Je pense à ma grand-mère

YannUbuntu · Le 30/08/2010, à 08:26

moi à ma mère qui remplit à ras-bord son EEE-PC de photos, et à mon frangin qui fait pareil avec des vidéos...

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#51 Le 23/07/2010, à 06:46

Re : Disque dur plein : risques ? limites ? solutions ?

#52 Le 23/07/2010, à 09:43

Re : Disque dur plein : risques ? limites ? solutions ?

#53 Le 23/07/2010, à 10:30

Re : Disque dur plein : risques ? limites ? solutions ?

#54 Le 23/07/2010, à 10:40

Re : Disque dur plein : risques ? limites ? solutions ?

#55 Le 23/07/2010, à 11:40

Re : Disque dur plein : risques ? limites ? solutions ?

#56 Le 23/07/2010, à 12:11

Re : Disque dur plein : risques ? limites ? solutions ?

#57 Le 23/07/2010, à 12:18

Re : Disque dur plein : risques ? limites ? solutions ?

#58 Le 23/07/2010, à 12:26

Re : Disque dur plein : risques ? limites ? solutions ?

#59 Le 23/07/2010, à 12:40

Re : Disque dur plein : risques ? limites ? solutions ?

#60 Le 23/07/2010, à 12:49

Re : Disque dur plein : risques ? limites ? solutions ?

#61 Le 23/07/2010, à 15:09

Re : Disque dur plein : risques ? limites ? solutions ?

#62 Le 26/07/2010, à 08:56

Re : Disque dur plein : risques ? limites ? solutions ?

#63 Le 26/07/2010, à 09:38

Re : Disque dur plein : risques ? limites ? solutions ?

#64 Le 26/07/2010, à 10:37

Re : Disque dur plein : risques ? limites ? solutions ?

#65 Le 26/07/2010, à 10:44

Re : Disque dur plein : risques ? limites ? solutions ?

#66 Le 26/07/2010, à 11:25

Re : Disque dur plein : risques ? limites ? solutions ?

#67 Le 26/07/2010, à 17:03

Re : Disque dur plein : risques ? limites ? solutions ?

#68 Le 27/07/2010, à 04:01

Re : Disque dur plein : risques ? limites ? solutions ?

#69 Le 28/08/2010, à 06:33

Re : Disque dur plein : risques ? limites ? solutions ?

#70 Le 28/08/2010, à 07:15

Re : Disque dur plein : risques ? limites ? solutions ?

#71 Le 28/08/2010, à 07:38

Re : Disque dur plein : risques ? limites ? solutions ?

#72 Le 29/08/2010, à 18:23

Re : Disque dur plein : risques ? limites ? solutions ?

#73 Le 30/08/2010, à 06:06

Re : Disque dur plein : risques ? limites ? solutions ?

#74 Le 30/08/2010, à 08:03

Re : Disque dur plein : risques ? limites ? solutions ?

#75 Le 30/08/2010, à 08:26

Re : Disque dur plein : risques ? limites ? solutions ?

Pied de page des forums