Quel est le problème avec cette image?
En haut, sortie de "df -h", en bas, gparted. Je pense que je manque beaucoup d’espace libre. Aucun problème autre que celui (pour le moment). Quelqu'un peut-il suggérer le meilleur moyen (non destructif) de corriger cela?
Sudo dumpe2fs -h/dev/sda3: (source http://Pastebin.com/nAvrdT4E )
Filesystem volume name: <none>
Last mounted on: /
Filesystem UUID: 9f6eff64-60d7-4eec-81d5-1e8acd818b38
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags: signed_directory_hash
Default mount options: (none)
Filesystem state: clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 1602496
Block count: 6406144
Reserved block count: 320306
Free blocks: 4842284
Free inodes: 1361222
First block: 0
Block size: 4096
Fragment size: 4096
Reserved GDT blocks: 1022
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 8176
Inode blocks per group: 511
RAID stride: 32692
Flex block group size: 16
Filesystem created: Sun Nov 8 18:18:13 2009
Last mount time: Tue Mar 1 01:04:27 2011
Last write time: Mon Feb 28 04:27:34 2011
Mount count: 16
Maximum mount count: 28
Last checked: Thu Feb 24 06:23:39 2011
Check interval: 15552000 (6 months)
Next check after: Tue Aug 23 07:23:39 2011
Lifetime writes: 227 GB
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 256
Required extra isize: 28
Desired extra isize: 28
Journal inode: 8
First Orphan inode: 268015
Default directory hash: half_md4
Directory Hash Seed: cc101517-e617-482b-a883-a72919419c84
Journal backup: inode blocks
Journal features: journal_incompat_revoke
Journal size: 128M
Journal length: 32768
Journal sequence: 0x001d3000
Journal start: 7787
fdisk et sortie séparée par requêtes: http://Pastebin.com/EGVH7Ken
SOLUTION: (merci Hamish Downer) Démarrez sur un liveCD et exécutez "Sudo e2fsck -f/dev/sda3" suivi de "Sudo resize2fs -p/dev/sda3"
Avez-vous redimensionné des partitions? En attendant la sortie de Sudo fdisk -l /dev/sda
, je me demande si la partition /dev/sda3
définie par la table de partition du disque (que fdisk nous indiquera) est de 70,50 Gio, alors que le système de fichiers de la partition ne contient que 25 Go.
Si cela est correct, il semblerait que GParted ait un bogue dans le sens où il suppose que le système de fichiers a la même taille que la partition de disque, demande au système de fichiers combien d’espace est disponible, puis suppose que le reste de la partition est utilisé.
De plus, si cela est correct, vous devriez pouvoir redimensionner le système de fichiers pour remplir la partition. Sauvegardez toutes les données de valeur, puis démarrez un live CD (ou une clé USB live) et sans montage de la partition, exécutez
Sudo resize2fs -p /dev/sda3
Puis laissez-le tranquille jusqu'à ce que ce soit fait et redémarrez.
Ceci m'est récemment arrivé parce que j'ai incorrectement utilisé dd
pour copier des données d'un lecteur à un autre. Les données étaient gardées en sécurité mais toutes les métadonnées du lecteur étaient foutues.
Dans la réponse (que j'ai modifiée pour montrer ce que j'ai fait), j'ai constaté que le fait de rynchroniser temporairement les données sur un autre lecteur, de reformater le disque et de recréer les partitions (en exécutant le programme d'installation, entre autres), puis de rynchroniser les données retour, corrigé.
Quoi que vous fassiez, si des données irremplaçables sont impliquées, obtenez une sauvegarde.