Hdd de 2To juste formaté contenant déjà 28GB ?

Support Debian
#1

je viens d’acheter un barracuda green de 2To. j’efface les partitions, j’en crée une seule, je monte le disque et df me dit qu’il y a 28GB d’utilisé, je ne comprends pas ou je fais une erreur.

[code]lotso@bigbenn ~ $ sudo fdisk /dev/sdb

WARNING: GPT (GUID Partition Table) detected on ‘/dev/sdb’! The util fdisk doesn’t support GPT. Use GNU Parted.

The device presents a logical sector size that is smaller than
the physical sector size. Aligning to a physical sector (or optimal
I/O) size boundary is recommended, or performance may be impacted.

Command (m for help): d
Selected partition 1

Command (m for help): n
Partition type:
p primary (0 primary, 0 extended, 4 free)
e extended
Select (default p): p
Partition number (1-4, default 1): 1
First sector (2048-3907029167, default 2048):
Using default value 2048
Last sector, +sectors or +size{K,M,G} (2048-3907029167, default 3907029167):
Using default value 3907029167

Command (m for help): p

Disk /dev/sdb: 2000.4 GB, 2000398934016 bytes
16 heads, 63 sectors/track, 3876021 cylinders, total 3907029168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk identifier: 0x00000000

Device Boot Start End Blocks Id System
/dev/sdb1 2048 3907029167 1953513560 83 Linux

Command (m for help): t
Selected partition 1
Hex code (type L to list codes): FD
Changed system type of partition 1 to fd (Linux raid autodetect)

Command (m for help): w
The partition table has been altered!

Calling ioctl() to re-read partition table.
Syncing disks.
lotso@bigbenn ~ $ sudo mount/dev/sdb1 /media/sdb1
sudo: mount/dev/sdb1: command not found
lotso@bigbenn ~ $ sudo mount /dev/sdb1 /media/sdb1
lotso@bigbenn ~ $ sudo df -h
Filesystem Size Used Avail Use% Mounted on
rootfs 75G 12G 60G 17% /
udev 10M 0 10M 0% /dev
tmpfs 1.2G 724K 1.2G 1% /run
/dev/disk/by-uuid/f0e6eea4-264d-42f2-97c1-0ad6d60e9e76 75G 12G 60G 17% /
tmpfs 5.0M 0 5.0M 0% /run/lock
tmpfs 3.0G 0 3.0G 0% /run/shm
/dev/sdb1 1.9T 28G 1.7T 2% /media/sdb1
[/code]

#2

Les journaux prennent une place non négligeable, former le en ext2 mais le jour d’ un mauvais démontage, tu pourras aller te faire un café le temps de la vérification du systeme…

#3

La table d’allocation prend aussi une place certaine, mais les journaux sont bien plus importants en effet :unamused:

#4

Il n’y a que moi qui remarque deux incohérences flagrantes ?

  1. La partition a été définie avec le type 0xfd (Linux RAID) mais montée directement au lieu d’être assemblée par mdadm dans un volume RAID /dev/mdX.

  2. Je n’ai pas vu passer de commande mkfs pour créer le système de fichiers sur la partition entre la création de celle-ci par fdisk et son montage par mount. A ma connaissance fdisk ne crée pas de système de fichiers sur les partitions qu’il crée (à plus forte raison s’il s’agit d’une partition de type RAID).

#5

tu as effectivement raison je n’ai ni fait un mkfs.extX ni assemblé la partition avec mdadm ce qui est mon objectif.
comme je veux créer un raid5 avec 2 disques et un missing qui contient encore des données, je voulais être certain que mes 2 disques servant à la création avaient bien la même taille.
c’est peut être stupide de monter un disque sans système de fichier, je ne sais pas.

#6

C’est surtout impossible. En fait on ne monte pas un disque ni une partition, ni quelque volume que ce soit, mais le système de fichiers qu’il contient.

Donc il y avait forcément déjà un système de fichiers à l’emplacement de la partition que tu as créée. Avec la commande mount, tu peux retrouver le type de système de fichiers qui a été monté à partir de cette partition. Tu peux aussi examiner son contenu avec ls.

PS: je n’ai pas compris l’histoire du RAID5.

#7

Ce taux de 28G sur 2T correspond bien à l’occupation des journaux d’un système ext3. Nul besoin que la partition ait été déclarée comme ext3, mount peut passer outre.
Comme il détruit une première partition au début, je suis prêt à parier qu’il avait fait des tests avant et formatté le disque en ext3, ça colle vraiment bien.
Cela dit effectivement la démarche est curieuse, il faudrait que je lise les messages jusqu’au bout avant de dire des aneries

#8

Cette table a été gérée avec fdisk alors qu’il y a au départ une table gpt.
Parted devrait coincer pour lire la table.
Pour la taille du fs, indépendamment des blocs réservés en standard il y a aussi la place occupée par les journaux/metadata.

Voir le man mkfs.ext4 il y a des options pour optimiser la place disponible en plus des 5% .
L’option -i est positionnée dans /etc/mke2fs.conf mais restent disponibles entre autre les options -I et -m.

Mais surtout voir si cette table ne doit pas être réparée avec gdisk.