Optimiser taille d'un disque - Qui m'a volé mes Go?

Support Debian
#1

Bonjour,

Je viens d’installer un disque supplémentaire de 500 Go.

Partitionné en primaire:
$ fdisk -l /dev/hdb

Disk /dev/hdb: 500.1 GB, 500107862016 bytes
255 heads, 63 sectors/track, 60801 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/hdb1               1       60801   488384032   83  Linux

Formaté en ext3:
$ mke2fs -j /dev/hdb1

[code]mke2fs 1.40-WIP (14-Nov-2006)
Étiquette de système de fichiers=
Type de système d’exploitation : Linux
Taille de bloc=4096 (log=2)
Taille de fragment=4096 (log=2)
61063168 i-noeuds, 122096000 blocs
6104800 blocs (5.00%) réservés pour le super utilisateur
Premier bloc de données=0
Nombre maximum de blocs du système de fichiers=0
3727 groupes de blocs
32768 blocs par groupe, 32768 fragments par groupe
16384 i-noeuds par groupe
Superblocs de secours stockés sur les blocs :
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968,
102400000

[/code]

122096000 blocs de 4096 octets me donnent bien mes 500 Go. Pas de problème. Je vois que 6104800 blocs, soit 25 Go, sont réservés au super utilisateur.

Première question: ces blocs réservés, c’est pour la journalisation?

Deuxième question: il devrait me rester 475 Go de disponible sur ma partition mais ce n’est apparemment pas le cas:
$ df -h /dev/hdb1

Sys. de fich. Tail. Occ. Disp. %Occ. Monté sur /dev/hdb1 459G 199M 435G 1% /data

Où sont passé les 16 Go manquants?

#2

Bon l’espace réservé pour le super utilisateur sert apparemment à ne pas bloquer l’OS si le disque n’a plus de place.

[quote].2. Reserved blocks

The -m option is probably the one of most use to non-experts. If the file system becomes filled and there is no more space to write, it is basically unusable because the operating system is constantly writing to disk. By default, five percent of the partition is reserved for use by the root user. This allows root to conduct administrative activities on the partition and perhaps move some data off. However, this is most critical when the partition contains / or home directories. For pure data partitions, this is just lost space. Five percent of a 250Gb partition is 12.5 Gb. Especially in the case of large partitions, it is safe to set the reserved space to the minimum, which is one percent.

mkfs.ext3 -m 1/dev/hdb1

creates a file system with only 1% of its space reserved for the root user. tune2fs -m can be used to adjust the reserved blocks after data is loaded on the partition. [/quote]

Comme il s’agit d’un disque supplémentaire j’ai mis les blocs réservés à zéro. Mais ça ne change pas grand chose après montage:

$ df -h /dev/hdb1 Sys. de fich. Tail. Occ. Disp. %Occ. Monté sur /dev/hdb1 459G 199M 459G 1% /data

Détails du système de fichiers:
$ dumpe2fs -h /dev/hdb1

dumpe2fs 1.40-WIP (14-Nov-2006) Filesystem volume name: <none> Last mounted on: <not available> Filesystem UUID: 2612da90-8768-4bdb-a129-308f91f67925 Filesystem magic number: 0xEF53 Filesystem revision #: 1 (dynamic) Filesystem features: has_journal resize_inode dir_index filetype needs_recovery sparse_super large_file Filesystem flags: signed directory hash Default mount options: (none) Filesystem state: clean Errors behavior: Continue Filesystem OS type: Linux Inode count: 61063168 Block count: 122096000 Reserved block count: 0 Free blocks: 120129064 Free inodes: 61063157 First block: 0 Block size: 4096 Fragment size: 4096 Reserved GDT blocks: 994 Blocks per group: 32768 Fragments per group: 32768 Inodes per group: 16384 Inode blocks per group: 512 Filesystem created: Thu Jul 10 10:44:26 2008 Last mount time: Thu Jul 10 10:51:00 2008 Last write time: Thu Jul 10 10:51:00 2008 Mount count: 1 Maximum mount count: 33 Last checked: Thu Jul 10 10:44:26 2008 Check interval: 15552000 (6 months) Next check after: Tue Jan 6 09:44:26 2009 Reserved blocks uid: 0 (user root) Reserved blocks gid: 0 (group root) First inode: 11 Inode size: 128 Journal inode: 8 Default directory hash: tea Directory Hash Seed: 854a8cc5-979b-446a-893c-88c47e6c0c1b Journal backup: inode blocks Taille du journal: 128M

Déjà je vois:
Free blocks: 120129064

Ça me fait déjà 5 Go de perdu. Je devrais réduire la taille des blocs?

#3

essaye avec : df -m tu aura plus de precision.

ensuite l’ext3 m’a un peux casser les pieds avec son scan tout 30 démarrage/jours bien que modifiable c’est pénible sure un dd de 320 go qui a beaucoup de partition.
je suis donc passer sous reiserfs qui gère automatiquement le journal. et je me tape pas un scan a la c** sur chaque partition c’est un peux plus lent aux boot mai sa va.:slightly_smiling:

#4

df -m me donne les mêmes infos.

J’ai essayé les block size de 1024. Pas de changement.

#5

je ne voit pas ou sa peux coincer ? :unamused: et depuis un live cd avec un autre système de fichier ?

#6

Étrange car le nombre de block fois 4000 plutôt que 4096, donne le même nombre de blocks que dans fdisk -l

Doit y avoir un problème avec les arrondis et un des calcul. 1024=1000 …

Il me semble que y’a une trucs avec le calcul que font les constructeur et ce 1024. Mais je sais plus quoi.

#7

J’osais pas poster ça tout à l’heure, mais c’est vrai que

459 × 1024 ~= 475 × 1000

donc y’a peut-être une histoire de confusion entre Giga et Gibi

#8

oui j’ai la même chose sur mon disque dur 500 Go aussi.

Je n’ai jamais vraiment cherché d’où pouvait venir cette différence.il me manque aussi à peu près 15 G aussi.

#9

[quote=“SGC.Alex”]J’osais pas poster ça tout à l’heure, mais c’est vrai que

459 × 1024 ~= 475 × 1000

donc y’a peut-être une histoire de confusion entre Giga et Gibi[/quote]

Peut-être mais un fdisk me donne:
Disk /dev/hdb: 500.1 GB, 500107862016 bytes

Pas de confusion possible. Ce sont des bytes.

Ce n’est pas le journal non plus, puisque dumpe2fs me donne un journal à 128 Mo. Comme précisé plus haut, changer la taille des blocs du FS ne donne rien, si ce n’est un formatage beaucoup plus long avec les blocs à 1024!

#10

[quote=“ripat”]Peut-être mais un fdisk me donne:
Disk /dev/hdb: 500.1 GB, 500107862016 bytes
[/quote]
C’est normal, je pense, à priori fdisk compte aussi en puissance de 10 (Edit:) pour les GB:

poiuy@debian:~$ concalc 500107862016/2^30 465.761741638183594
Soit 465.761741638183594 Gio.
Le reste de l’espace est perdu lors du formatage, soit 6 Gio environ.

#11

C’est effectivement bien ça. Vous avez tous raison. Et en plus il me semble l’avoir déjà lu sur ce forum.

Pour convertir les Go constructeur (base décimale) en Go binaires (Gio ou Gib):

Ko (1000/1024) = 0.976 Mo (1000/1024)^2 = 0.954 Go (1000/1024)^3 = 0.931

Discussion sur la confusion:
en.wikipedia.org/wiki/Binary_pre … _confusion

fdisk utilise la notation décimale et df la binaire! Pour afficher df en décimal: $ df --si et là, tout correspond et je retrouve mes 500 Go.
gnu.org/software/coreutils/m … Block-size

Quand arrêtera-t’on de nous tromper? Que tout le monde parle de Gibi un point c’est tout.

Vous imaginez les différentes bases de calculs auxquelles nous sommes confrontés? Décimal, hexadécimal, binaire, octal. Qu’il y a 60 minutes dans une heure, les pintes (garçon! deux pintes), les livres, les pieds et pouces. Au secours! Mes neurones ne suivent plus!

Explication du contexte historique:

[quote]Once upon a time, computer professionals noticed that 2^10 was very nearly equal to 1000 and started using the SI prefix “kilo” to mean 1024. That worked well enough for a decade or two because everybody who talked kilobytes knew that the term implied 1024 bytes. But, almost overnight a much more numerous “everybody” bought computers, and the trade computer professionals needed to talk to physicists and engineers and even to ordinary people, most of whom know that a kilometer is 1000 meters and a kilogram is 1000 grams.
physics.nist.gov/cuu/Units/binary.html[/quote]

#12

[quote=“ripat”]Quand arrêtera-t’on de nous tromper? Que tout le monde parle de Gibi un point c’est tout.
[/quote]
Tu n’avais qu’à prendre un disque de 537 Go, tu aurais eu ton compte.
:smt003