Bonjour,
Je suis nouveau sous BSD et je me pose une petite question à laquelle je
n'ais pas trouvé de réponse pour l'instant.
Je viens d'installer une FreeBSD 5.3 sans problème, jusqu'au moment où
j'ai voulu rajouter un nouveau disque dur.
Le modèle est un Hitashi Deskstar IC35L120AVV07-0
avec données constructeur LBA 201.045.600 secteurs CHS 16383/16/63
Le bios indique : 15017/63/255 ce qui fait 241.248.105 secteurs, soit 115Go.
dmesg lui donne 239.340/16/63 ce qui fait 241.254.720 secteurs, soit
également 115Go.
Maintenant je lance fdisk via sysinstall, il m'indique que la géométrie
n'est pas bonne en mettant celle de dmesg mais une fois le message passé
il indique bien la géométrie indiquée par le bios soit : 15017/63/255.
par acquit de conscience je change tout de même manuellement la
géométrie du disque pour qu'elle corresponde à celle du bios.
Ensuite je crée ma partition et il me donne la structure suivante :
Offset Size(ST) End Name PType Desc Subtype
0 63 62 - 12 unused 0
63 241248042 241248104 ad0s1 8 freebsd 165
241248105 6615 241254719 - 12 unused 0
Maintenant je passe a disklabel pour créer une slice en UFS2 le résultat
étant le suivant :
Disk: ad0 Partition name: ad0s1 Free: 0 blocks (0MB)
Part Mount Size Newfs Part Mount Size Newf
---- ----- ---- ----- ---- ----- ---- ----
ad0s1d /mnt/bkp1 115GB UFS2+S Y
Je fais un bsdlabel -An /dev/ad0s1d dont le résultat est :
type: ESDI
disk: ad0s1
label:
flags:
bytes/sector: 512
sectors/track: 63
tracks/cylinder: 16
sectors/cylinder: 1008
cylinders: 239340
sectors/unit: 241254720
rpm: 3600
interleave: 1
trackskew: 0
cylinderskew: 0
headswitch: 0 # milliseconds
track-to-track seek: 0 # milliseconds
drivedata: 0
8 partitions:
# size offset fstype [fsize bsize bps/cpg]
c: 241248042 63 unused 0 0 # "raw" part,
don't edit
d: 241248042 63 4.2BSD 2048 16384 28544
bsdlabel: partition c doesn't start at 0!
bsdlabel: partition c doesn't cover the whole unit!
bsdlabel: An incorrect partition c may cause problems for standard
system utilities
Donc pour lui la structure du disque n'est pas celle indiquée lors de
fdisk, mais la taille de la slice d correspond bien au résultat de
disklabel.
Donc jusqu'à maintenant ça va à peut près, mais si je fais un df -h pour
voir l'espace disque disponible là ça se complique car j'obtiens le
résultat suivant :
Filesystem Size Used Avail Capacity Mounted on
/dev/da0s1a 248M 35M 193M 15% /
devfs 1.0K 1.0K 0B 100% /dev
/dev/da0s1e 248M 6.0K 228M 0% /tmp
/dev/da0s1f 2.4G 460M 1.8G 20% /usr
/dev/da0s1d 248M 1.1M 227M 0% /var
devfs 1.0K 1.0K 0B 100% /var/named/dev
/dev/ad0s1d 111G 4.0K 102G 0% /mnt/bkp1
donc déja la taille passe de 115Go à 111Go mais en plus l'espace
disponible indiqué n'est plus que de 102Go avec une occupation de 0%.
Si quelqu'un pouvait m'indiquer d'où vient le problème, est ce df qui me
donne un résultat érroné ou ai je fais une boulette quelque part ?
A noter que sous linux avec un kernel 2.6.9 le même type de disque
partionné en reiserfs j'ai un résultat cohérant avec df, c.a.d :
Sys. de fich. Tail. Occ. Disp. %Occ. Monté sur
/dev/hda1 116G 84G 32G 73% /mnt/backup1
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
F. Senault
donc déja la taille passe de 115Go à 111Go mais en plus l'espace disponible indiqué n'est plus que de 102Go avec une occupation de 0%.
Si quelqu'un pouvait m'indiquer d'où vient le problème, est ce df qui me donne un résultat érroné ou ai je fais une boulette quelque part ?
Ce n'est pas un problème, c'est /by design/ (mais pas moins surprenant, je sais !).
En gros, le système de fichiers de FreeBSD réserve un pourcentage du disque utilisable uniquement par root, 8% par défaut - 111*92/1002. Généralement, les gens sont surpris quand ils trouvent un espace libre _négatif_ sur le disque (indiquant que root a commencé à taper dans l'espace réservé).
C'est renseigné dans la page de man de tunefs, où il est également dit que c'est une mauvaise idée de trop baisser ce nombre (notamment pour permettre au FS d'éviter la fragmentation). Au fait, tunefs -p device (ou mountpoint) te donnera quelques autres paramètres de ton filesystem.
Au fait, sur le fond du reste du mail : je n'ai _jamais_ eu à me plaindre de fdisk quand il trouvait des paramètres différents de ceux du BIOS. En d'autres mots, je n'ai jamais cherché à remettre quelque chose d'autre que ce qu'il indiquait. Et le message de bsdlabel qui se plaint d'une partition C qui ne commence pas au début du disque m'inquiéterait...
Je serais toi, je laisserais le système faire ce qu'il pense bon, sans me soucier du BIOS (qui n'est pas toujours la meilleure source d'informations).
Fred -- I'm running free yeah, I'm running free I'm running free yeah, Oh I'm running free Spent the night in an L.A. jail, and listened to the sirens wail They ain't got a thing on me, I'm running wild, I'm running free. (Iron Maiden, Running Free)
donc déja la taille passe de 115Go à 111Go mais en plus l'espace
disponible indiqué n'est plus que de 102Go avec une occupation de 0%.
Si quelqu'un pouvait m'indiquer d'où vient le problème, est ce df qui me
donne un résultat érroné ou ai je fais une boulette quelque part ?
Ce n'est pas un problème, c'est /by design/ (mais pas moins surprenant,
je sais !).
En gros, le système de fichiers de FreeBSD réserve un pourcentage du
disque utilisable uniquement par root, 8% par défaut - 111*92/1002.
Généralement, les gens sont surpris quand ils trouvent un espace libre
_négatif_ sur le disque (indiquant que root a commencé à taper dans
l'espace réservé).
C'est renseigné dans la page de man de tunefs, où il est également dit
que c'est une mauvaise idée de trop baisser ce nombre (notamment pour
permettre au FS d'éviter la fragmentation). Au fait, tunefs -p device
(ou mountpoint) te donnera quelques autres paramètres de ton filesystem.
Au fait, sur le fond du reste du mail : je n'ai _jamais_ eu à me
plaindre de fdisk quand il trouvait des paramètres différents de ceux du
BIOS. En d'autres mots, je n'ai jamais cherché à remettre quelque chose
d'autre que ce qu'il indiquait. Et le message de bsdlabel qui se plaint
d'une partition C qui ne commence pas au début du disque
m'inquiéterait...
Je serais toi, je laisserais le système faire ce qu'il pense bon, sans
me soucier du BIOS (qui n'est pas toujours la meilleure source
d'informations).
Fred
--
I'm running free yeah, I'm running free I'm running free yeah, Oh I'm
running free Spent the night in an L.A. jail, and listened to the
sirens wail They ain't got a thing on me, I'm running wild, I'm
running free. (Iron Maiden, Running Free)
donc déja la taille passe de 115Go à 111Go mais en plus l'espace disponible indiqué n'est plus que de 102Go avec une occupation de 0%.
Si quelqu'un pouvait m'indiquer d'où vient le problème, est ce df qui me donne un résultat érroné ou ai je fais une boulette quelque part ?
Ce n'est pas un problème, c'est /by design/ (mais pas moins surprenant, je sais !).
En gros, le système de fichiers de FreeBSD réserve un pourcentage du disque utilisable uniquement par root, 8% par défaut - 111*92/1002. Généralement, les gens sont surpris quand ils trouvent un espace libre _négatif_ sur le disque (indiquant que root a commencé à taper dans l'espace réservé).
C'est renseigné dans la page de man de tunefs, où il est également dit que c'est une mauvaise idée de trop baisser ce nombre (notamment pour permettre au FS d'éviter la fragmentation). Au fait, tunefs -p device (ou mountpoint) te donnera quelques autres paramètres de ton filesystem.
Au fait, sur le fond du reste du mail : je n'ai _jamais_ eu à me plaindre de fdisk quand il trouvait des paramètres différents de ceux du BIOS. En d'autres mots, je n'ai jamais cherché à remettre quelque chose d'autre que ce qu'il indiquait. Et le message de bsdlabel qui se plaint d'une partition C qui ne commence pas au début du disque m'inquiéterait...
Je serais toi, je laisserais le système faire ce qu'il pense bon, sans me soucier du BIOS (qui n'est pas toujours la meilleure source d'informations).
Fred -- I'm running free yeah, I'm running free I'm running free yeah, Oh I'm running free Spent the night in an L.A. jail, and listened to the sirens wail They ain't got a thing on me, I'm running wild, I'm running free. (Iron Maiden, Running Free)
pornin
According to wence :
Maintenant je lance fdisk via sysinstall, il m'indique que la géométrie n'est pas bonne en mettant celle de dmesg mais une fois le message passé il indique bien la géométrie indiquée par le bios soit : 15017/63/255.
Le mieux est de le laisser faire. De toutes façons, l'information est inscrite deux fois pour chaque partition (enfin, "slice" en dialecte BSD), une fois en CHS (cylindres/têtes/secteurs) et une autre fois sous la forme d'un compte absolu de secteurs depuis le premier secteur du disque. Tous les OS décents sur PC (post-MsDos en gros) utilisent ce deuxième compteur et méprisent le premier, qui est traditionnellement peu fiable. Les disques durs mentent au bios quant à leur vraie géométrie. Le bios ment à l'OS quant à la géométrie annoncée par le disque.
En bref, le plus simple est de laisser sysinstall râler un peu et faire ce qu'il estime être "le mieux".
par acquit de conscience je change tout de même manuellement la géométrie du disque pour qu'elle corresponde à celle du bios.
C'est probablement cette action qui entraîne le deuxième message, qui lui est moins courant. Ça ne devrait pas poser de problème dans la pratique.
donc déja la taille passe de 115Go à 111Go mais en plus l'espace disponible indiqué n'est plus que de 102Go avec une occupation de 0%.
Les 4 Go qui manquent entre 111 et 115 correspondent aux inodes et à d'autres métadonnées. Ce sont des données qui ne servent pas pour stocker le contenu même des fichiers ni même leur nom, mais d'autres informations qui sont tout autant cruciales pour que les choses se passent bien (des références internes sur la position des blocs contenant les données, les droits d'accès,...).
Ça, c'est normal. C'est vrai pour tous les filesystems, mais les modalités précises peuvent varier. Typiquement, sous reiserfs, la place pour les inodes et autres métadonnées est allouée dynamiquement. Aussi, on commence avec 115 Go, mais on ne peut pas écrire pour 115 Go de données, parce que chaque fichier vient avec ses métadonnées qui prennent de la place ; un fichier de 1 Mo prend en fait environ 1.05 Mo sur le disque.
Pour le passage de 111 à 102, c'est pour la fragmentation : afin de mieux contrôler le placement des données sur le disque (pour que les accès soient rapides), les algorithmes utilisés ont besoin d'un peu de place libre, ce qui ce conçoit : c'est plus facile de trouver un placement qui permet de garder une fragmentation faible quand le disque n'est pas quasiment plein. La place excédentaire n'est pas perdue, mais elle est réservée à root. cf man tunefs, option -m. Le seuil est par défaut à 8% ; il n'est pas conseillé de descendre à 5% ou en dessous, parce qu'alors l'OS change sa stratégie d'allocation, et en choisit une autre qui est plus économe mais aussi plus lente. Si on laisse la valeur par défaut, ce qui compte, c'est surtout la place effectivement prise par les fichiers : au-delà de 85% occupés, les performances chutent. Ces concepts sont vrais pour tous les filesystems, et donc affectent aussi ext2 ou reiserfs. La différence est plutôt que dans certaines combinaisons OS + filesystem + outils de gestion, cette histoire de perte de performance est parfois passée sous silence...
Tout ça est en fait assez traditionnel : la chute de performances est de moins en moins sensible, parce que les disques durs ont maintenant des caches, et la machine a elle aussi pas mal de cpu et de ram, ce qui lisse fortement tout ça. Dans une utilisation courante, je ne pense pas qu'on puisse détecter de visu la perte en performance sur un disque chargé ras la gueule. Par ailleurs, le faible coût et la faible qualité des disques fait que le "disque dur plein" est une espèce en voie de disparition : de plus en plus, le disque meurt avant d'être rempli.
En résumé : tout va bien.
--Thomas Pornin
According to wence <wence@free.fr>:
Maintenant je lance fdisk via sysinstall, il m'indique que la géométrie
n'est pas bonne en mettant celle de dmesg mais une fois le message passé
il indique bien la géométrie indiquée par le bios soit : 15017/63/255.
Le mieux est de le laisser faire. De toutes façons, l'information est
inscrite deux fois pour chaque partition (enfin, "slice" en dialecte
BSD), une fois en CHS (cylindres/têtes/secteurs) et une autre fois sous
la forme d'un compte absolu de secteurs depuis le premier secteur du
disque. Tous les OS décents sur PC (post-MsDos en gros) utilisent ce
deuxième compteur et méprisent le premier, qui est traditionnellement
peu fiable. Les disques durs mentent au bios quant à leur vraie
géométrie. Le bios ment à l'OS quant à la géométrie annoncée par le
disque.
En bref, le plus simple est de laisser sysinstall râler un peu et faire
ce qu'il estime être "le mieux".
par acquit de conscience je change tout de même manuellement la
géométrie du disque pour qu'elle corresponde à celle du bios.
C'est probablement cette action qui entraîne le deuxième message,
qui lui est moins courant. Ça ne devrait pas poser de problème dans
la pratique.
donc déja la taille passe de 115Go à 111Go mais en plus l'espace
disponible indiqué n'est plus que de 102Go avec une occupation de 0%.
Les 4 Go qui manquent entre 111 et 115 correspondent aux inodes et
à d'autres métadonnées. Ce sont des données qui ne servent pas pour
stocker le contenu même des fichiers ni même leur nom, mais d'autres
informations qui sont tout autant cruciales pour que les choses se
passent bien (des références internes sur la position des blocs
contenant les données, les droits d'accès,...).
Ça, c'est normal. C'est vrai pour tous les filesystems, mais les
modalités précises peuvent varier. Typiquement, sous reiserfs, la
place pour les inodes et autres métadonnées est allouée dynamiquement.
Aussi, on commence avec 115 Go, mais on ne peut pas écrire pour 115 Go
de données, parce que chaque fichier vient avec ses métadonnées qui
prennent de la place ; un fichier de 1 Mo prend en fait environ 1.05 Mo
sur le disque.
Pour le passage de 111 à 102, c'est pour la fragmentation : afin de
mieux contrôler le placement des données sur le disque (pour que les
accès soient rapides), les algorithmes utilisés ont besoin d'un peu
de place libre, ce qui ce conçoit : c'est plus facile de trouver un
placement qui permet de garder une fragmentation faible quand le disque
n'est pas quasiment plein. La place excédentaire n'est pas perdue, mais
elle est réservée à root. cf man tunefs, option -m. Le seuil est par
défaut à 8% ; il n'est pas conseillé de descendre à 5% ou en dessous,
parce qu'alors l'OS change sa stratégie d'allocation, et en choisit une
autre qui est plus économe mais aussi plus lente. Si on laisse la valeur
par défaut, ce qui compte, c'est surtout la place effectivement prise
par les fichiers : au-delà de 85% occupés, les performances chutent.
Ces concepts sont vrais pour tous les filesystems, et donc affectent
aussi ext2 ou reiserfs. La différence est plutôt que dans certaines
combinaisons OS + filesystem + outils de gestion, cette histoire de
perte de performance est parfois passée sous silence...
Tout ça est en fait assez traditionnel : la chute de performances est
de moins en moins sensible, parce que les disques durs ont maintenant
des caches, et la machine a elle aussi pas mal de cpu et de ram, ce qui
lisse fortement tout ça. Dans une utilisation courante, je ne pense pas
qu'on puisse détecter de visu la perte en performance sur un disque
chargé ras la gueule. Par ailleurs, le faible coût et la faible qualité
des disques fait que le "disque dur plein" est une espèce en voie de
disparition : de plus en plus, le disque meurt avant d'être rempli.
Maintenant je lance fdisk via sysinstall, il m'indique que la géométrie n'est pas bonne en mettant celle de dmesg mais une fois le message passé il indique bien la géométrie indiquée par le bios soit : 15017/63/255.
Le mieux est de le laisser faire. De toutes façons, l'information est inscrite deux fois pour chaque partition (enfin, "slice" en dialecte BSD), une fois en CHS (cylindres/têtes/secteurs) et une autre fois sous la forme d'un compte absolu de secteurs depuis le premier secteur du disque. Tous les OS décents sur PC (post-MsDos en gros) utilisent ce deuxième compteur et méprisent le premier, qui est traditionnellement peu fiable. Les disques durs mentent au bios quant à leur vraie géométrie. Le bios ment à l'OS quant à la géométrie annoncée par le disque.
En bref, le plus simple est de laisser sysinstall râler un peu et faire ce qu'il estime être "le mieux".
par acquit de conscience je change tout de même manuellement la géométrie du disque pour qu'elle corresponde à celle du bios.
C'est probablement cette action qui entraîne le deuxième message, qui lui est moins courant. Ça ne devrait pas poser de problème dans la pratique.
donc déja la taille passe de 115Go à 111Go mais en plus l'espace disponible indiqué n'est plus que de 102Go avec une occupation de 0%.
Les 4 Go qui manquent entre 111 et 115 correspondent aux inodes et à d'autres métadonnées. Ce sont des données qui ne servent pas pour stocker le contenu même des fichiers ni même leur nom, mais d'autres informations qui sont tout autant cruciales pour que les choses se passent bien (des références internes sur la position des blocs contenant les données, les droits d'accès,...).
Ça, c'est normal. C'est vrai pour tous les filesystems, mais les modalités précises peuvent varier. Typiquement, sous reiserfs, la place pour les inodes et autres métadonnées est allouée dynamiquement. Aussi, on commence avec 115 Go, mais on ne peut pas écrire pour 115 Go de données, parce que chaque fichier vient avec ses métadonnées qui prennent de la place ; un fichier de 1 Mo prend en fait environ 1.05 Mo sur le disque.
Pour le passage de 111 à 102, c'est pour la fragmentation : afin de mieux contrôler le placement des données sur le disque (pour que les accès soient rapides), les algorithmes utilisés ont besoin d'un peu de place libre, ce qui ce conçoit : c'est plus facile de trouver un placement qui permet de garder une fragmentation faible quand le disque n'est pas quasiment plein. La place excédentaire n'est pas perdue, mais elle est réservée à root. cf man tunefs, option -m. Le seuil est par défaut à 8% ; il n'est pas conseillé de descendre à 5% ou en dessous, parce qu'alors l'OS change sa stratégie d'allocation, et en choisit une autre qui est plus économe mais aussi plus lente. Si on laisse la valeur par défaut, ce qui compte, c'est surtout la place effectivement prise par les fichiers : au-delà de 85% occupés, les performances chutent. Ces concepts sont vrais pour tous les filesystems, et donc affectent aussi ext2 ou reiserfs. La différence est plutôt que dans certaines combinaisons OS + filesystem + outils de gestion, cette histoire de perte de performance est parfois passée sous silence...
Tout ça est en fait assez traditionnel : la chute de performances est de moins en moins sensible, parce que les disques durs ont maintenant des caches, et la machine a elle aussi pas mal de cpu et de ram, ce qui lisse fortement tout ça. Dans une utilisation courante, je ne pense pas qu'on puisse détecter de visu la perte en performance sur un disque chargé ras la gueule. Par ailleurs, le faible coût et la faible qualité des disques fait que le "disque dur plein" est une espèce en voie de disparition : de plus en plus, le disque meurt avant d'être rempli.
En résumé : tout va bien.
--Thomas Pornin
wence
Merci à vous pour vos explications et le temps que vous avez du y accorder.
Je comprend mieux maintenant d'où venait le problème, il concernait mes lacunes dans ce domaine. Car même si j'ai étudié les systèmes de fichiers dans mes cours de noyau, les parties optimisation à l'usage et représentation des données à l'utilisateur n'ont pas été abordées. Cela me donne un nouvel intérêt à lire le livre sur l'implémentation du système FreeBSD dès que j'aurais le temps.
Merci à vous pour vos explications et le temps que vous avez du y accorder.
Je comprend mieux maintenant d'où venait le problème, il concernait mes
lacunes dans ce domaine. Car même si j'ai étudié les systèmes de
fichiers dans mes cours de noyau, les parties optimisation à l'usage et
représentation des données à l'utilisateur n'ont pas été abordées. Cela
me donne un nouvel intérêt à lire le livre sur l'implémentation du
système FreeBSD dès que j'aurais le temps.
Merci à vous pour vos explications et le temps que vous avez du y accorder.
Je comprend mieux maintenant d'où venait le problème, il concernait mes lacunes dans ce domaine. Car même si j'ai étudié les systèmes de fichiers dans mes cours de noyau, les parties optimisation à l'usage et représentation des données à l'utilisateur n'ont pas été abordées. Cela me donne un nouvel intérêt à lire le livre sur l'implémentation du système FreeBSD dès que j'aurais le temps.
Patrick Lamaizière
écrivait :
C'est renseigné dans la page de man de tunefs, où il est également dit que c'est une mauvaise idée de trop baisser ce nombre (notamment pour permettre au FS d'éviter la fragmentation). Au fait, tunefs -p device (ou mountpoint) te donnera quelques autres paramètres de ton filesystem.
D'accord, mais est-ce que ça dépend de la taille du FS ? 8% sur un FS de plusieurs Go ça fait pas mal de place perdue. Cela dépend peut-être aussi des fichiers stockés ? Par exemple j'ai une partition de sauvegarde où je stocke des gros tar de plusieurs Go je descendrais bien ce % là.
<fred@lacave.net> écrivait :
C'est renseigné dans la page de man de tunefs, où il est également dit
que c'est une mauvaise idée de trop baisser ce nombre (notamment pour
permettre au FS d'éviter la fragmentation). Au fait, tunefs -p device
(ou mountpoint) te donnera quelques autres paramètres de ton filesystem.
D'accord, mais est-ce que ça dépend de la taille du FS ? 8% sur un FS de
plusieurs Go ça fait pas mal de place perdue. Cela dépend peut-être aussi
des fichiers stockés ? Par exemple j'ai une partition de sauvegarde où je
stocke des gros tar de plusieurs Go je descendrais bien ce % là.
C'est renseigné dans la page de man de tunefs, où il est également dit que c'est une mauvaise idée de trop baisser ce nombre (notamment pour permettre au FS d'éviter la fragmentation). Au fait, tunefs -p device (ou mountpoint) te donnera quelques autres paramètres de ton filesystem.
D'accord, mais est-ce que ça dépend de la taille du FS ? 8% sur un FS de plusieurs Go ça fait pas mal de place perdue. Cela dépend peut-être aussi des fichiers stockés ? Par exemple j'ai une partition de sauvegarde où je stocke des gros tar de plusieurs Go je descendrais bien ce % là.
F. Senault
écrivait :
C'est renseigné dans la page de man de tunefs, où il est également dit que c'est une mauvaise idée de trop baisser ce nombre (notamment pour permettre au FS d'éviter la fragmentation). Au fait, tunefs -p device (ou mountpoint) te donnera quelques autres paramètres de ton filesystem.
D'accord, mais est-ce que ça dépend de la taille du FS ? 8% sur un FS de plusieurs Go ça fait pas mal de place perdue. Cela dépend peut-être aussi des fichiers stockés ? Par exemple j'ai une partition de sauvegarde où je stocke des gros tar de plusieurs Go je descendrais bien ce % là.
Si c'est pour du backup, teste avec des %ages en dessous de 5 ; comme la doc le dit, tu passeras en mode d'optimisation space et tu perdras des performances, mais ça ne doit pas être trop gênant à ce niveau.
Fred -- A se changer en Roi A hurler à la lune A traquer la fortune Tout ça pour trainer son poids Au risque de s'y plaire Au moment de s'y croire Sonnez les courants d'air Faites donner l'exutoire Il faudrait qu'on s'élève Au fond il a d'la classe (Noir Désir, Comme elle vient)
<fred@lacave.net> écrivait :
C'est renseigné dans la page de man de tunefs, où il est également dit
que c'est une mauvaise idée de trop baisser ce nombre (notamment pour
permettre au FS d'éviter la fragmentation). Au fait, tunefs -p device
(ou mountpoint) te donnera quelques autres paramètres de ton filesystem.
D'accord, mais est-ce que ça dépend de la taille du FS ? 8% sur un FS de
plusieurs Go ça fait pas mal de place perdue. Cela dépend peut-être aussi
des fichiers stockés ? Par exemple j'ai une partition de sauvegarde où je
stocke des gros tar de plusieurs Go je descendrais bien ce % là.
Si c'est pour du backup, teste avec des %ages en dessous de 5 ; comme la
doc le dit, tu passeras en mode d'optimisation space et tu perdras des
performances, mais ça ne doit pas être trop gênant à ce niveau.
Fred
--
A se changer en Roi A hurler à la lune A traquer la fortune Tout ça
pour trainer son poids Au risque de s'y plaire Au moment de s'y croire
Sonnez les courants d'air Faites donner l'exutoire Il faudrait qu'on
s'élève Au fond il a d'la classe (Noir Désir, Comme elle vient)
C'est renseigné dans la page de man de tunefs, où il est également dit que c'est une mauvaise idée de trop baisser ce nombre (notamment pour permettre au FS d'éviter la fragmentation). Au fait, tunefs -p device (ou mountpoint) te donnera quelques autres paramètres de ton filesystem.
D'accord, mais est-ce que ça dépend de la taille du FS ? 8% sur un FS de plusieurs Go ça fait pas mal de place perdue. Cela dépend peut-être aussi des fichiers stockés ? Par exemple j'ai une partition de sauvegarde où je stocke des gros tar de plusieurs Go je descendrais bien ce % là.
Si c'est pour du backup, teste avec des %ages en dessous de 5 ; comme la doc le dit, tu passeras en mode d'optimisation space et tu perdras des performances, mais ça ne doit pas être trop gênant à ce niveau.
Fred -- A se changer en Roi A hurler à la lune A traquer la fortune Tout ça pour trainer son poids Au risque de s'y plaire Au moment de s'y croire Sonnez les courants d'air Faites donner l'exutoire Il faudrait qu'on s'élève Au fond il a d'la classe (Noir Désir, Comme elle vient)
