# Problème commande df renvoie mauvais resultat **URL:** \ **Category:** Support Debian\ **Created:** [Septembre 4, 2020, 11:43 UTC](https://www.debian-fr.org/t/probleme-commande-df-renvoie-mauvais-resultat/82777 "2020-09-04T11:43:06Z")\ **Posts on this page:** 11\ **Page:** 1
**Author:** ![facine41](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/f/fbc32d/32.png) [@facine41](https://www.debian-fr.org/u/facine41)\ **Post date:** [Septembre 4, 2020, 11:43 UTC](https://www.debian-fr.org/t/probleme-commande-df-renvoie-mauvais-resultat/82777/1 "2020-09-04T11:43:06Z")
Bonjour, J’ai un soucis sur mon NAS OpenMediaVault, avec 2 disque de 4To en RAID, le resultat renvoyé par la commande df est completement faux : ```nohighlight root@NAS2:~# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 3.7T 0 disk └─md0 9:0 0 7.3T 0 linear /srv/dev-disk-by-label-Media sdb 8:16 0 3.7T 0 disk └─md0 9:0 0 7.3T 0 linear /srv/dev-disk-by-label-Media sr0 11:0 1 551M 0 rom vda 254:0 0 20G 0 disk ├─vda1 254:1 0 16G 0 part / ├─vda2 254:2 0 1K 0 part └─vda5 254:5 0 4G 0 part [SWAP] root@NAS2:~# root@NAS2:~# root@NAS2:~# root@NAS2:~# df -h Filesystem Size Used Avail Use% Mounted on udev 3.9G 0 3.9G 0% /dev tmpfs 797M 19M 779M 3% /run /dev/vda1 16G 7.2G 7.7G 49% / tmpfs 3.9G 8.0K 3.9G 1% /dev/shm tmpfs 5.0M 0 5.0M 0% /run/lock tmpfs 3.9G 0 3.9G 0% /sys/fs/cgroup tmpfs 3.9G 100K 3.9G 1% /tmp **/dev/md0 7.3T 3.3T 0 100% /srv/dev-disk-by-label-Media** root@NAS2:~# root@NAS2:~# uname -a Linux NAS2.lan 5.4.0-0.bpo.2-amd64 #1 SMP Debian 5.4.8-1~bpo10+1 (2020-01-07) x86_64 GNU/Linux ``` On voit bien que la capacité de /dev/md0 est de 7.3To, Utilisé 3.3 mais full à 100% ?! Merci de votre aide… ---
**Author:** ![anon70622873](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/278dde/32.png) [@anon70622873](https://www.debian-fr.org/u/anon70622873)\ **Post date:** [Septembre 4, 2020, 11:59 UTC](https://www.debian-fr.org/t/probleme-commande-df-renvoie-mauvais-resultat/82777/2 "2020-09-04T11:59:08Z")
Bonjour, Il n’y a aucune raison que la commande df renvoie un mauvais résultat. Je suppose donc que le système de fichiers sur /dev/md0 n’occupe que la moitié de l’espace disponible : 3.3 To sur 7.3 To Il faudrait voir les retours de : ```auto fdisk -l ``` et ```auto mdadm -D /dev/md0 ``` ---
**Author:** ![facine41](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/f/fbc32d/32.png) [@facine41](https://www.debian-fr.org/u/facine41)\ **Post date:** [Septembre 4, 2020, 12:01 UTC](https://www.debian-fr.org/t/probleme-commande-df-renvoie-mauvais-resultat/82777/3 "2020-09-04T12:01:20Z")
Merci pour ton aide 😉 Voici les resultats : ```nohighlight root@NAS2:~# fdisk -l Disk /dev/vda: 20 GiB, 21474836480 bytes, 41943040 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0x0181e66d Device Boot Start End Sectors Size Id Type /dev/vda1 * 2048 33554431 33552384 16G 83 Linux /dev/vda2 33556478 41940991 8384514 4G 5 Extended /dev/vda5 33556480 41940991 8384512 4G 82 Linux swap / Solaris Disk /dev/sdb: 3.7 TiB, 4000787030016 bytes, 7814037168 sectors Disk model: QEMU HARDDISK Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk /dev/sda: 3.7 TiB, 4000787030016 bytes, 7814037168 sectors Disk model: QEMU HARDDISK Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk /dev/md0: 7.3 TiB, 8001303527424 bytes, 15627545952 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes root@NAS2:~# ``` ```nohighlight root@NAS2:~# mdadm -D /dev/md0 /dev/md0: Version : 1.2 Creation Time : Wed Jan 22 13:03:25 2020 Raid Level : linear Array Size : 7813772976 (7451.79 GiB 8001.30 GB) Raid Devices : 2 Total Devices : 2 Persistence : Superblock is persistent Update Time : Wed Jan 22 13:03:25 2020 State : clean Active Devices : 2 Working Devices : 2 Failed Devices : 0 Spare Devices : 0 Rounding : 0K Consistency Policy : none Name : NAS2.lan:HDD (local to host NAS2.lan) UUID : 2e7245f4:efefc440:6c241c26:50a86392 Events : 0 Number Major Minor RaidDevice State 0 8 16 0 active sync /dev/sdb 1 8 0 1 active sync /dev/sda root@NAS2:~# ``` ---
**Author:** ![anon70622873](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/278dde/32.png) [@anon70622873](https://www.debian-fr.org/u/anon70622873)\ **Post date:** [Septembre 4, 2020, 12:08 UTC](https://www.debian-fr.org/t/probleme-commande-df-renvoie-mauvais-resultat/82777/4 "2020-09-04T12:08:49Z")
Je ne vois aucune partition avec un système de fichiers ni sur sda et sdb (possible si la RAID est construit à partir du disque entier, mais peu recommandé). Pour voir les partitions sur md0 il faudrait le retour de (désolé j’aurais du demander cela à la place de fdisk) : ```auto parted -l ``` Comment as-tu construit ton RAID linear et créé les partitions ? N.B. : avec un RAID linear tu utilises pleinement la capacité des deux disques, mais en cas de défaillance de l’un des deux tu perds tout. ---
**Author:** ![facine41](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/f/fbc32d/32.png) [@facine41](https://www.debian-fr.org/u/facine41)\ **Post date:** [Septembre 4, 2020, 12:12 UTC](https://www.debian-fr.org/t/probleme-commande-df-renvoie-mauvais-resultat/82777/5 "2020-09-04T12:12:29Z")
J’ai créé le RAID via l’interface web de OpenMediaVault. ```nohighlight root@NAS2:~# parted -l Error: /dev/sda: unrecognised disk label Model: ATA QEMU HARDDISK (scsi) Disk /dev/sda: 4001GB Sector size (logical/physical): 512B/512B Partition Table: unknown Disk Flags: Error: /dev/sdb: unrecognised disk label Model: ATA QEMU HARDDISK (scsi) Disk /dev/sdb: 4001GB Sector size (logical/physical): 512B/512B Partition Table: unknown Disk Flags: Model: Linux Software RAID Array (md) Disk /dev/md0: 8001GB Sector size (logical/physical): 512B/512B Partition Table: loop Disk Flags: Number Start End Size File system Flags 1 0.00B 8001GB 8001GB btrfs Warning: Unable to open /dev/sr0 read-write (Read-only file system). /dev/sr0 has been opened read-only. Model: QEMU QEMU DVD-ROM (scsi) Disk /dev/sr0: 578MB Sector size (logical/physical): 2048B/2048B Partition Table: mac Disk Flags: Number Start End Size File system Name Flags 1 2048B 6143B 4096B Apple 2 2755kB 5671kB 2916kB EFI Model: Virtio Block Device (virtblk) Disk /dev/vda: 21.5GB Sector size (logical/physical): 512B/512B Partition Table: msdos Disk Flags: Number Start End Size Type File system Flags 1 1049kB 17.2GB 17.2GB primary ext4 boot 2 17.2GB 21.5GB 4293MB extended 5 17.2GB 21.5GB 4293MB logical linux-swap(v1) root@NAS2:~# ``` ---
**Author:** ![anon70622873](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/278dde/32.png) [@anon70622873](https://www.debian-fr.org/u/anon70622873)\ **Post date:** [Septembre 4, 2020, 12:13 UTC](https://www.debian-fr.org/t/probleme-commande-df-renvoie-mauvais-resultat/82777/6 "2020-09-04T12:13:16Z")
Le retour de : ```auto parted -l ``` STP ---
**Author:** ![facine41](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/f/fbc32d/32.png) [@facine41](https://www.debian-fr.org/u/facine41)\ **Post date:** [Septembre 4, 2020, 12:14 UTC](https://www.debian-fr.org/t/probleme-commande-df-renvoie-mauvais-resultat/82777/7 "2020-09-04T12:14:30Z")
```nohighlight root@NAS2:~# parted -l Error: /dev/sda: unrecognised disk label Model: ATA QEMU HARDDISK (scsi) Disk /dev/sda: 4001GB Sector size (logical/physical): 512B/512B Partition Table: unknown Disk Flags: Error: /dev/sdb: unrecognised disk label Model: ATA QEMU HARDDISK (scsi) Disk /dev/sdb: 4001GB Sector size (logical/physical): 512B/512B Partition Table: unknown Disk Flags: Model: Linux Software RAID Array (md) Disk /dev/md0: 8001GB Sector size (logical/physical): 512B/512B Partition Table: loop Disk Flags: Number Start End Size File system Flags 1 0.00B 8001GB 8001GB btrfs Warning: Unable to open /dev/sr0 read-write (Read-only file system). /dev/sr0 has been opened read-only. Model: QEMU QEMU DVD-ROM (scsi) Disk /dev/sr0: 578MB Sector size (logical/physical): 2048B/2048B Partition Table: mac Disk Flags: Number Start End Size File system Name Flags 1 2048B 6143B 4096B Apple 2 2755kB 5671kB 2916kB EFI Model: Virtio Block Device (virtblk) Disk /dev/vda: 21.5GB Sector size (logical/physical): 512B/512B Partition Table: msdos Disk Flags: Number Start End Size Type File system Flags 1 1049kB 17.2GB 17.2GB primary ext4 boot 2 17.2GB 21.5GB 4293MB extended 5 17.2GB 21.5GB 4293MB logical linux-swap(v1) root@NAS2:~# ``` ---
**Author:** ![facine41](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/f/fbc32d/32.png) [@facine41](https://www.debian-fr.org/u/facine41)\ **Post date:** [Septembre 4, 2020, 12:24 UTC](https://www.debian-fr.org/t/probleme-commande-df-renvoie-mauvais-resultat/82777/8 "2020-09-04T12:24:37Z")
Alors, j’ai supprimé un fichier de 7Go environ, et retapé la commande df : ```nohighlight root@NAS2:~# df -h Filesystem Size Used Avail Use% Mounted on udev 3.9G 0 3.9G 0% /dev tmpfs 797M 19M 779M 3% /run /dev/vda1 16G 7.2G 7.7G 49% / tmpfs 3.9G 8.0K 3.9G 1% /dev/shm tmpfs 5.0M 0 5.0M 0% /run/lock tmpfs 3.9G 0 3.9G 0% /sys/fs/cgroup tmpfs 3.9G 100K 3.9G 1% /tmp **/dev/md0 7.3T 3.3T 4.1T 45% /srv/dev-disk-by-label-Media** root@NAS2:~# ``` Les autres commandes renvoient la meme chose qu’avant… ---
**Author:** ![anon70622873](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/278dde/32.png) [@anon70622873](https://www.debian-fr.org/u/anon70622873)\ **Post date:** [Septembre 4, 2020, 1:02 UTC](https://www.debian-fr.org/t/probleme-commande-df-renvoie-mauvais-resultat/82777/9 "2020-09-04T13:02:12Z")
Ah ? je suppose que c’est dû au système de fichiers utilisé : BTRFS > **[Btrfs](https://fr.wikipedia.org/wiki/Btrfs#Co%C3%BBt_associ%C3%A9_en_occupation_disque_et_lacune_sur_la_haute_disponibilit%C3%A9)** > > Btrfs (B-tree file system, prononcé ButterFS,) est un système de fichiers des années 2010 fondé sur le Copy-On-Write (copie sur écriture en français) sous licence GNU GPL, développé conjointement par Oracle, Red Hat, Fujitsu, Intel, SUSE, STRATO AG (en) et autres. En 2012, alors qu'il n'était pas encore considéré comme tout à fait stable, un effort intense de développement et de test est fourni par la communauté afin de faire de Btrfs le successeur de ext4 et ext3, systèmes de fich Btrfs offre ... ---
**Author:** ![facine41](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/f/fbc32d/32.png) [@facine41](https://www.debian-fr.org/u/facine41)\ **Post date:** [Septembre 4, 2020, 6:32 UTC](https://www.debian-fr.org/t/probleme-commande-df-renvoie-mauvais-resultat/82777/10 "2020-09-04T18:32:54Z")
Toujours le même problème… **`/dev/md0 7.3T 3.3T 0 100% /srv/dev-disk-by-label-Media`** Si quelqu’un a une idée, je suis preneur ! ---
**Author:** ![anon70622873](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/278dde/32.png) [@anon70622873](https://www.debian-fr.org/u/anon70622873)\ **Post date:** [Septembre 4, 2020, 7:52 UTC](https://www.debian-fr.org/t/probleme-commande-df-renvoie-mauvais-resultat/82777/11 "2020-09-04T19:52:28Z")
Est-ce que tu as lu le lien que j’ai donné ? > Le fonctionnement interne de Btrfs rend pratiquement impossible de déterminer la quantité d’espace libre : la commande « df » ne correspond en effet qu’à l’espace apparent, pas à l’espace réel pouvant être bien plus grand. Auparavant ce type de problème ne se rencontrait sous Linux qu’avec les fichiers creux (ou « troués »).