BONNE ANNEE !!
Le 13/01/2019 19:35, Pascal Hambourg a écrit :
Eviter que les utilisateurs,
Il existe une gestion de Quotas pour ça, il me semble, non ?
les logs ou les caches divers bouffent tout l'espace disque.
Possible de gérer pas les quotas ?
Choisir les types de systèmes de fichiers les plus adaptés au contenu.
Aurais-tu des exemples pour que je comprenne l'intérêt ?
Hormis le swap, celui-là, je le connais.
Monter les parties statiques de l'arborescence en lecture seule.
Ca, c'est une mesure de sécurité supplémentaire, non ? Genre, si jamais une vérole arrive à craquer le compte root, elle ne peut pas
effacer de fichiers ?Limiter l'étendue de la corruption d'un système de fichiers.
Ca arrive ? Autant je visualise bien des problèmes de disque dur (je ne compte plus le nombre que j'ai déposé à la déchetterie),
autant je vois moins sur une partition. Je crois bien que je n'ai jamais eu ce genre de soucis.
Simplifier les sauvegardes et la restauration.
Comme par exemple faire une copie "brute" (par dd ?) d'une partition sur un média de sauvegarde ?
Simplifier la réinstallation avec conservation des données.
Ca, je vois bien, ça doit faire 20 ans que je sépare le système et les données sur des partitions différentes, quand ce ne sont pas
des disques différents.
Pascal en Trophy
BONNE ANNEE !!
Le 13/01/2019 19:35, Pascal Hambourg a écrit :
Eviter que les utilisateurs,
Il existe une gestion de Quotas pour ça, il me semble, non ?
les logs ou les caches divers bouffent tout l'espace disque.
Possible de gérer pas les quotas ?
Choisir les types de systèmes de fichiers les plus adaptés au contenu.
Aurais-tu des exemples pour que je comprenne l'intérêt ?
Hormis le swap, celui-là, je le connais.
Monter les parties statiques de l'arborescence en lecture seule.
Ca, c'est une mesure de sécurité supplémentaire, non ? Genre, si jamais une vérole arrive à craquer le compte root, elle ne peut pas
effacer de fichiers ?
Limiter l'étendue de la corruption d'un système de fichiers.
Ca arrive ? Autant je visualise bien des problèmes de disque dur (je ne compte plus le nombre que j'ai déposé à la déchetterie),
autant je vois moins sur une partition. Je crois bien que je n'ai jamais eu ce genre de soucis.
Simplifier les sauvegardes et la restauration.
Comme par exemple faire une copie "brute" (par dd ?) d'une partition sur un média de sauvegarde ?
Simplifier la réinstallation avec conservation des données.
Ca, je vois bien, ça doit faire 20 ans que je sépare le système et les données sur des partitions différentes, quand ce ne sont pas
des disques différents.
Pascal en Trophy
BONNE ANNEE !!
Le 13/01/2019 19:35, Pascal Hambourg a écrit :
Eviter que les utilisateurs,
Il existe une gestion de Quotas pour ça, il me semble, non ?
les logs ou les caches divers bouffent tout l'espace disque.
Possible de gérer pas les quotas ?
Choisir les types de systèmes de fichiers les plus adaptés au contenu.
Aurais-tu des exemples pour que je comprenne l'intérêt ?
Hormis le swap, celui-là, je le connais.
Monter les parties statiques de l'arborescence en lecture seule.
Ca, c'est une mesure de sécurité supplémentaire, non ? Genre, si jamais une vérole arrive à craquer le compte root, elle ne peut pas
effacer de fichiers ?Limiter l'étendue de la corruption d'un système de fichiers.
Ca arrive ? Autant je visualise bien des problèmes de disque dur (je ne compte plus le nombre que j'ai déposé à la déchetterie),
autant je vois moins sur une partition. Je crois bien que je n'ai jamais eu ce genre de soucis.
Simplifier les sauvegardes et la restauration.
Comme par exemple faire une copie "brute" (par dd ?) d'une partition sur un média de sauvegarde ?
Simplifier la réinstallation avec conservation des données.
Ca, je vois bien, ça doit faire 20 ans que je sépare le système et les données sur des partitions différentes, quand ce ne sont pas
des disques différents.
Pascal en Trophy
Eviter que les utilisateurs, les logs ou les caches divers bouffent tout
l'espace disque.
Choisir les types de systèmes de fichiers les plus adaptés au contenu.
Monter les parties statiques de l'arborescence en lecture seule. Limiter
l'étendue de la corruption d'un système de fichiers. Simplifier les
sauvegardes et la restauration.
Simplifier la réinstallation avec conservation des données.
Eviter que les utilisateurs, les logs ou les caches divers bouffent tout
l'espace disque.
Choisir les types de systèmes de fichiers les plus adaptés au contenu.
Monter les parties statiques de l'arborescence en lecture seule. Limiter
l'étendue de la corruption d'un système de fichiers. Simplifier les
sauvegardes et la restauration.
Simplifier la réinstallation avec conservation des données.
Eviter que les utilisateurs, les logs ou les caches divers bouffent tout
l'espace disque.
Choisir les types de systèmes de fichiers les plus adaptés au contenu.
Monter les parties statiques de l'arborescence en lecture seule. Limiter
l'étendue de la corruption d'un système de fichiers. Simplifier les
sauvegardes et la restauration.
Simplifier la réinstallation avec conservation des données.
Là d'accord. J'aurai peut-être dû aussi faire une partoche /tmp (ou /var/
tmp ?)
Là d'accord. J'aurai peut-être dû aussi faire une partoche /tmp (ou /var/
tmp ?)
Là d'accord. J'aurai peut-être dû aussi faire une partoche /tmp (ou /var/
tmp ?)
Le Sun, 13 Jan 2019 19:35:43 +0100, Pascal Hambourg a écrit :Monter les parties statiques de l'arborescence en lecture seule. Limiter
l'étendue de la corruption d'un système de fichiers. Simplifier les
sauvegardes et la restauration.
Tout ça est très bien «monter les parties statiques, c'est à dire qu'est-
ce que tu appelle partie statique ?
Tous les packages sont susceptibles
d'être mis à jour un jour où l'autre, les bibliothèques, la documentation
rien de tout ça n'est statique.
Le Sun, 13 Jan 2019 19:35:43 +0100, Pascal Hambourg a écrit :
Monter les parties statiques de l'arborescence en lecture seule. Limiter
l'étendue de la corruption d'un système de fichiers. Simplifier les
sauvegardes et la restauration.
Tout ça est très bien «monter les parties statiques, c'est à dire qu'est-
ce que tu appelle partie statique ?
Tous les packages sont susceptibles
d'être mis à jour un jour où l'autre, les bibliothèques, la documentation
rien de tout ça n'est statique.
Le Sun, 13 Jan 2019 19:35:43 +0100, Pascal Hambourg a écrit :Monter les parties statiques de l'arborescence en lecture seule. Limiter
l'étendue de la corruption d'un système de fichiers. Simplifier les
sauvegardes et la restauration.
Tout ça est très bien «monter les parties statiques, c'est à dire qu'est-
ce que tu appelle partie statique ?
Tous les packages sont susceptibles
d'être mis à jour un jour où l'autre, les bibliothèques, la documentation
rien de tout ça n'est statique.
Jo Engo , dans le message
<pan$a07a5$ac932206$89be2af8$, a écrit :Là d'accord. J'aurai peut-être dû aussi faire une partoche /tmp (ou /var/
tmp ?)
Pour /tmp, beaucoup de distributions se sont mises à monter un tmpfs
(système de fichiers stockant les données en mémoire, swappable si
nécessaire), et ça marche plutôt bien en général.
Jo Engo , dans le message
<pan$a07a5$ac932206$89be2af8$3ab0267d@icite.fr>, a écrit :
Là d'accord. J'aurai peut-être dû aussi faire une partoche /tmp (ou /var/
tmp ?)
Pour /tmp, beaucoup de distributions se sont mises à monter un tmpfs
(système de fichiers stockant les données en mémoire, swappable si
nécessaire), et ça marche plutôt bien en général.
Jo Engo , dans le message
<pan$a07a5$ac932206$89be2af8$, a écrit :Là d'accord. J'aurai peut-être dû aussi faire une partoche /tmp (ou /var/
tmp ?)
Pour /tmp, beaucoup de distributions se sont mises à monter un tmpfs
(système de fichiers stockant les données en mémoire, swappable si
nécessaire), et ça marche plutôt bien en général.
Pour /tmp, beaucoup de distributions se sont mises à monter un tmpfs
(système de fichiers stockant les données en mémoire, swappable si
nécessaire), et ça marche plutôt bien en général.
Ce qui m'a toujours semblé étonnant pour une utilisation en desktop lors
de laquelle l'utilisateur peut-être amené à manier des données bien plus
large que la quantité de mémoire disponible et donc à faire swapper le
système.
Je n'ai jamais pris le temps de faire des tests mais il me semble que
certaines applications copient des données dans /tmp qui peuvent
s'avérer assez volumineuses (probablement la plupart des logiciels
d'édition d'images, audio et vidéo).
J'imagine que l'intérêt est de gagner en performance lors de l'accès à
ces données mais je ne suis pas persuadé que le jeu en vaille la
chandelle d'autant plus si finalement les données finissent sur le
disque en cas de swap.
Pour /tmp, beaucoup de distributions se sont mises à monter un tmpfs
(système de fichiers stockant les données en mémoire, swappable si
nécessaire), et ça marche plutôt bien en général.
Ce qui m'a toujours semblé étonnant pour une utilisation en desktop lors
de laquelle l'utilisateur peut-être amené à manier des données bien plus
large que la quantité de mémoire disponible et donc à faire swapper le
système.
Je n'ai jamais pris le temps de faire des tests mais il me semble que
certaines applications copient des données dans /tmp qui peuvent
s'avérer assez volumineuses (probablement la plupart des logiciels
d'édition d'images, audio et vidéo).
J'imagine que l'intérêt est de gagner en performance lors de l'accès à
ces données mais je ne suis pas persuadé que le jeu en vaille la
chandelle d'autant plus si finalement les données finissent sur le
disque en cas de swap.
Pour /tmp, beaucoup de distributions se sont mises à monter un tmpfs
(système de fichiers stockant les données en mémoire, swappable si
nécessaire), et ça marche plutôt bien en général.
Ce qui m'a toujours semblé étonnant pour une utilisation en desktop lors
de laquelle l'utilisateur peut-être amené à manier des données bien plus
large que la quantité de mémoire disponible et donc à faire swapper le
système.
Je n'ai jamais pris le temps de faire des tests mais il me semble que
certaines applications copient des données dans /tmp qui peuvent
s'avérer assez volumineuses (probablement la plupart des logiciels
d'édition d'images, audio et vidéo).
J'imagine que l'intérêt est de gagner en performance lors de l'accès à
ces données mais je ne suis pas persuadé que le jeu en vaille la
chandelle d'autant plus si finalement les données finissent sur le
disque en cas de swap.
Bonjour,
Le 15/01/2019 à 20:03, Doug a écrit dans le message
<q1lapv$8sl$ :Pour /tmp, beaucoup de distributions se sont mises à monter un tmpfs
(système de fichiers stockant les données en mémoire, swappable si
nécessaire), et ça marche plutôt bien en général.
Ce qui m'a toujours semblé étonnant pour une utilisation en desktop lors
de laquelle l'utilisateur peut-être amené à manier des données bien plus
large que la quantité de mémoire disponible et donc à faire swapper le
système.
Je n'ai jamais pris le temps de faire des tests mais il me semble que
certaines applications copient des données dans /tmp qui peuvent
s'avérer assez volumineuses (probablement la plupart des logiciels
d'édition d'images, audio et vidéo).
J'imagine que l'intérêt est de gagner en performance lors de l'accès à
ces données mais je ne suis pas persuadé que le jeu en vaille la
chandelle d'autant plus si finalement les données finissent sur le
disque en cas de swap.
Personnellement, vu ce que j'utilise comme mémoire :
% free -m
total used free shared buff/cache available
Mem: 7909 1464 3560 70 2884 6076
Swap: 4387 0 4387
je n'ai aucun remord à avoir 4 Go disponible pour /tmp quand j'en ai
besoin, par exemple pour compiler un programme, surtout qu'en temps
normal ça ne coûte rien :
% df -h /tmp
Filesystem Size Used Avail Use% Mounted on
tmpfs 3.9G 160K 3.9G 1% /tmp
Il m'arrive d'avoir à augmenter /tmp à 7 Go pour pouvoir compiler des
gros morceaux comme android-studio mais sinon ça ne me pose aucun
problème depuis plusieurs années, je n'ai jamais constaté de swap (4 Go
c'est quand même confortable).
Bonjour,
Le 15/01/2019 à 20:03, Doug a écrit dans le message
<q1lapv$8sl$1@golgoth99.hacktruck.net> :
Pour /tmp, beaucoup de distributions se sont mises à monter un tmpfs
(système de fichiers stockant les données en mémoire, swappable si
nécessaire), et ça marche plutôt bien en général.
Ce qui m'a toujours semblé étonnant pour une utilisation en desktop lors
de laquelle l'utilisateur peut-être amené à manier des données bien plus
large que la quantité de mémoire disponible et donc à faire swapper le
système.
Je n'ai jamais pris le temps de faire des tests mais il me semble que
certaines applications copient des données dans /tmp qui peuvent
s'avérer assez volumineuses (probablement la plupart des logiciels
d'édition d'images, audio et vidéo).
J'imagine que l'intérêt est de gagner en performance lors de l'accès à
ces données mais je ne suis pas persuadé que le jeu en vaille la
chandelle d'autant plus si finalement les données finissent sur le
disque en cas de swap.
Personnellement, vu ce que j'utilise comme mémoire :
% free -m
total used free shared buff/cache available
Mem: 7909 1464 3560 70 2884 6076
Swap: 4387 0 4387
je n'ai aucun remord à avoir 4 Go disponible pour /tmp quand j'en ai
besoin, par exemple pour compiler un programme, surtout qu'en temps
normal ça ne coûte rien :
% df -h /tmp
Filesystem Size Used Avail Use% Mounted on
tmpfs 3.9G 160K 3.9G 1% /tmp
Il m'arrive d'avoir à augmenter /tmp à 7 Go pour pouvoir compiler des
gros morceaux comme android-studio mais sinon ça ne me pose aucun
problème depuis plusieurs années, je n'ai jamais constaté de swap (4 Go
c'est quand même confortable).
Bonjour,
Le 15/01/2019 à 20:03, Doug a écrit dans le message
<q1lapv$8sl$ :Pour /tmp, beaucoup de distributions se sont mises à monter un tmpfs
(système de fichiers stockant les données en mémoire, swappable si
nécessaire), et ça marche plutôt bien en général.
Ce qui m'a toujours semblé étonnant pour une utilisation en desktop lors
de laquelle l'utilisateur peut-être amené à manier des données bien plus
large que la quantité de mémoire disponible et donc à faire swapper le
système.
Je n'ai jamais pris le temps de faire des tests mais il me semble que
certaines applications copient des données dans /tmp qui peuvent
s'avérer assez volumineuses (probablement la plupart des logiciels
d'édition d'images, audio et vidéo).
J'imagine que l'intérêt est de gagner en performance lors de l'accès à
ces données mais je ne suis pas persuadé que le jeu en vaille la
chandelle d'autant plus si finalement les données finissent sur le
disque en cas de swap.
Personnellement, vu ce que j'utilise comme mémoire :
% free -m
total used free shared buff/cache available
Mem: 7909 1464 3560 70 2884 6076
Swap: 4387 0 4387
je n'ai aucun remord à avoir 4 Go disponible pour /tmp quand j'en ai
besoin, par exemple pour compiler un programme, surtout qu'en temps
normal ça ne coûte rien :
% df -h /tmp
Filesystem Size Used Avail Use% Mounted on
tmpfs 3.9G 160K 3.9G 1% /tmp
Il m'arrive d'avoir à augmenter /tmp à 7 Go pour pouvoir compiler des
gros morceaux comme android-studio mais sinon ça ne me pose aucun
problème depuis plusieurs années, je n'ai jamais constaté de swap (4 Go
c'est quand même confortable).
Ce qui me gène c'est le fait que ce soit un choix par défaut et donc non
réèllement consenti par l'utilisateur qui ne s'y connait pas
nécessairement assez pour vérifier tout ça.
Évidemment lorsque la configuration matérielle dispose de quantité de
RAM qui frole le déraisonnable le problème ne se pose pas de la même
manière que lorsqu'il s'agit d'un portable moyen de gamme de plus de 5
ans.
Mon poste fixe dispose d'une quantité de RAM totalement extravagante mais
pas mon portable, dont le poids des années commence à se faire sentir de
manière régulière, qui dispose malgré tout de disques de tailles sérieuses.
Créer par défaut un tmpfs sans tenir compte de la taille de la RAM et
des disques présents ou de l'utilisation qui sera faite de la machine me
semble un choix pauvre et c'est le reproche que je fais à la plupart des
"grandes distributions" qui ont une tendance à appliquer des règles qui
viennent d'on ne sait où de manière trop dogmatique à mon goût.
Ce qui me gène c'est le fait que ce soit un choix par défaut et donc non
réèllement consenti par l'utilisateur qui ne s'y connait pas
nécessairement assez pour vérifier tout ça.
Évidemment lorsque la configuration matérielle dispose de quantité de
RAM qui frole le déraisonnable le problème ne se pose pas de la même
manière que lorsqu'il s'agit d'un portable moyen de gamme de plus de 5
ans.
Mon poste fixe dispose d'une quantité de RAM totalement extravagante mais
pas mon portable, dont le poids des années commence à se faire sentir de
manière régulière, qui dispose malgré tout de disques de tailles sérieuses.
Créer par défaut un tmpfs sans tenir compte de la taille de la RAM et
des disques présents ou de l'utilisation qui sera faite de la machine me
semble un choix pauvre et c'est le reproche que je fais à la plupart des
"grandes distributions" qui ont une tendance à appliquer des règles qui
viennent d'on ne sait où de manière trop dogmatique à mon goût.
Ce qui me gène c'est le fait que ce soit un choix par défaut et donc non
réèllement consenti par l'utilisateur qui ne s'y connait pas
nécessairement assez pour vérifier tout ça.
Évidemment lorsque la configuration matérielle dispose de quantité de
RAM qui frole le déraisonnable le problème ne se pose pas de la même
manière que lorsqu'il s'agit d'un portable moyen de gamme de plus de 5
ans.
Mon poste fixe dispose d'une quantité de RAM totalement extravagante mais
pas mon portable, dont le poids des années commence à se faire sentir de
manière régulière, qui dispose malgré tout de disques de tailles sérieuses.
Créer par défaut un tmpfs sans tenir compte de la taille de la RAM et
des disques présents ou de l'utilisation qui sera faite de la machine me
semble un choix pauvre et c'est le reproche que je fais à la plupart des
"grandes distributions" qui ont une tendance à appliquer des règles qui
viennent d'on ne sait où de manière trop dogmatique à mon goût.
Le 16/01/2019 à 11:49, Doug713705 a écrit :Ce qui me gène c'est le fait que ce soit un choix par défaut et donc non
réèllement consenti par l'utilisateur qui ne s'y connait pas
nécessairement assez pour vérifier tout ça.
Évidemment lorsque la configuration matérielle dispose de quantité de
RAM qui frole le déraisonnable le problème ne se pose pas de la même
manière que lorsqu'il s'agit d'un portable moyen de gamme de plus de 5
ans.
Mon poste fixe dispose d'une quantité de RAM totalement extravagante mais
pas mon portable, dont le poids des années commence à se faire sentir de
manière régulière, qui dispose malgré tout de disques de tailles sérieuses.
Créer par défaut un tmpfs sans tenir compte de la taille de la RAM et
des disques présents ou de l'utilisation qui sera faite de la machine me
semble un choix pauvre et c'est le reproche que je fais à la plupart des
"grandes distributions" qui ont une tendance à appliquer des règles qui
viennent d'on ne sait où de manière trop dogmatique à mon goût.
Pourtant le répertoire /tmp existe toujours et en fonctionnement le
système y met des fichiers, très peu en effet mais est-ce qu'il ne sert
pas en cas de "débordement"?
Dans ce cas c'est acceptable car cela améliore les performances notamment
en cas de très nombreux petits fichiers qui sont créés plus rapidement en RAM,
et cette zone peut être aussi grande que l'on veut (mais par défaut elle fait
partie de /).
Le 16/01/2019 à 11:49, Doug713705 a écrit :
Ce qui me gène c'est le fait que ce soit un choix par défaut et donc non
réèllement consenti par l'utilisateur qui ne s'y connait pas
nécessairement assez pour vérifier tout ça.
Évidemment lorsque la configuration matérielle dispose de quantité de
RAM qui frole le déraisonnable le problème ne se pose pas de la même
manière que lorsqu'il s'agit d'un portable moyen de gamme de plus de 5
ans.
Mon poste fixe dispose d'une quantité de RAM totalement extravagante mais
pas mon portable, dont le poids des années commence à se faire sentir de
manière régulière, qui dispose malgré tout de disques de tailles sérieuses.
Créer par défaut un tmpfs sans tenir compte de la taille de la RAM et
des disques présents ou de l'utilisation qui sera faite de la machine me
semble un choix pauvre et c'est le reproche que je fais à la plupart des
"grandes distributions" qui ont une tendance à appliquer des règles qui
viennent d'on ne sait où de manière trop dogmatique à mon goût.
Pourtant le répertoire /tmp existe toujours et en fonctionnement le
système y met des fichiers, très peu en effet mais est-ce qu'il ne sert
pas en cas de "débordement"?
Dans ce cas c'est acceptable car cela améliore les performances notamment
en cas de très nombreux petits fichiers qui sont créés plus rapidement en RAM,
et cette zone peut être aussi grande que l'on veut (mais par défaut elle fait
partie de /).
Le 16/01/2019 à 11:49, Doug713705 a écrit :Ce qui me gène c'est le fait que ce soit un choix par défaut et donc non
réèllement consenti par l'utilisateur qui ne s'y connait pas
nécessairement assez pour vérifier tout ça.
Évidemment lorsque la configuration matérielle dispose de quantité de
RAM qui frole le déraisonnable le problème ne se pose pas de la même
manière que lorsqu'il s'agit d'un portable moyen de gamme de plus de 5
ans.
Mon poste fixe dispose d'une quantité de RAM totalement extravagante mais
pas mon portable, dont le poids des années commence à se faire sentir de
manière régulière, qui dispose malgré tout de disques de tailles sérieuses.
Créer par défaut un tmpfs sans tenir compte de la taille de la RAM et
des disques présents ou de l'utilisation qui sera faite de la machine me
semble un choix pauvre et c'est le reproche que je fais à la plupart des
"grandes distributions" qui ont une tendance à appliquer des règles qui
viennent d'on ne sait où de manière trop dogmatique à mon goût.
Pourtant le répertoire /tmp existe toujours et en fonctionnement le
système y met des fichiers, très peu en effet mais est-ce qu'il ne sert
pas en cas de "débordement"?
Dans ce cas c'est acceptable car cela améliore les performances notamment
en cas de très nombreux petits fichiers qui sont créés plus rapidement en RAM,
et cette zone peut être aussi grande que l'on veut (mais par défaut elle fait
partie de /).
Le 16/01/2019 à 11:49, Doug713705 a écrit :Ce qui me gène c'est le fait que ce soit un choix par défaut et donc non
réèllement consenti par l'utilisateur qui ne s'y connait pas
nécessairement assez pour vérifier tout ça.
Évidemment lorsque la configuration matérielle dispose de quantité de
RAM qui frole le déraisonnable le problème ne se pose pas de la même
manière que lorsqu'il s'agit d'un portable moyen de gamme de plus de 5
ans.
Mon poste fixe dispose d'une quantité de RAM totalement extravagante mais
pas mon portable, dont le poids des années commence à se faire sentir de
manière régulière, qui dispose malgré tout de disques de tailles sérieuses.
Créer par défaut un tmpfs sans tenir compte de la taille de la RAM et
des disques présents ou de l'utilisation qui sera faite de la machine me
semble un choix pauvre et c'est le reproche que je fais à la plupart des
"grandes distributions" qui ont une tendance à appliquer des règles qui
viennent d'on ne sait où de manière trop dogmatique à mon goût.
Pourtant le répertoire /tmp existe toujours et en fonctionnement le
système y met des fichiers, très peu en effet mais est-ce qu'il ne sert
pas en cas de "débordement"?
Dans ce cas c'est acceptable car cela améliore les performances notamment
en cas de très nombreux petits fichiers qui sont créés plus rapidement en RAM,
et cette zone peut être aussi grande que l'on veut (mais par défaut elle fait
partie de /).
Le 16/01/2019 à 11:49, Doug713705 a écrit :
Ce qui me gène c'est le fait que ce soit un choix par défaut et donc non
réèllement consenti par l'utilisateur qui ne s'y connait pas
nécessairement assez pour vérifier tout ça.
Évidemment lorsque la configuration matérielle dispose de quantité de
RAM qui frole le déraisonnable le problème ne se pose pas de la même
manière que lorsqu'il s'agit d'un portable moyen de gamme de plus de 5
ans.
Mon poste fixe dispose d'une quantité de RAM totalement extravagante mais
pas mon portable, dont le poids des années commence à se faire sentir de
manière régulière, qui dispose malgré tout de disques de tailles sérieuses.
Créer par défaut un tmpfs sans tenir compte de la taille de la RAM et
des disques présents ou de l'utilisation qui sera faite de la machine me
semble un choix pauvre et c'est le reproche que je fais à la plupart des
"grandes distributions" qui ont une tendance à appliquer des règles qui
viennent d'on ne sait où de manière trop dogmatique à mon goût.
Pourtant le répertoire /tmp existe toujours et en fonctionnement le
système y met des fichiers, très peu en effet mais est-ce qu'il ne sert
pas en cas de "débordement"?
Dans ce cas c'est acceptable car cela améliore les performances notamment
en cas de très nombreux petits fichiers qui sont créés plus rapidement en RAM,
et cette zone peut être aussi grande que l'on veut (mais par défaut elle fait
partie de /).
Le 16/01/2019 à 11:49, Doug713705 a écrit :Ce qui me gène c'est le fait que ce soit un choix par défaut et donc non
réèllement consenti par l'utilisateur qui ne s'y connait pas
nécessairement assez pour vérifier tout ça.
Évidemment lorsque la configuration matérielle dispose de quantité de
RAM qui frole le déraisonnable le problème ne se pose pas de la même
manière que lorsqu'il s'agit d'un portable moyen de gamme de plus de 5
ans.
Mon poste fixe dispose d'une quantité de RAM totalement extravagante mais
pas mon portable, dont le poids des années commence à se faire sentir de
manière régulière, qui dispose malgré tout de disques de tailles sérieuses.
Créer par défaut un tmpfs sans tenir compte de la taille de la RAM et
des disques présents ou de l'utilisation qui sera faite de la machine me
semble un choix pauvre et c'est le reproche que je fais à la plupart des
"grandes distributions" qui ont une tendance à appliquer des règles qui
viennent d'on ne sait où de manière trop dogmatique à mon goût.
Pourtant le répertoire /tmp existe toujours et en fonctionnement le
système y met des fichiers, très peu en effet mais est-ce qu'il ne sert
pas en cas de "débordement"?
Dans ce cas c'est acceptable car cela améliore les performances notamment
en cas de très nombreux petits fichiers qui sont créés plus rapidement en RAM,
et cette zone peut être aussi grande que l'on veut (mais par défaut elle fait
partie de /).