Problème commande df renvoie mauvais resultat

facine41 · Septembre 4, 2020, 11:43

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 :

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…

anon70622873 · Septembre 4, 2020, 11:59

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 :

fdisk -l

et

 mdadm -D /dev/md0

facine41 · Septembre 4, 2020, 12:01

Merci pour ton aide

Voici les resultats :

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:~#

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:~#

anon70622873 · Septembre 4, 2020, 12:08

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) :

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.

facine41 · Septembre 4, 2020, 12:12

J’ai créé le RAID via l’interface web de OpenMediaVault.

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:~#

anon70622873 · Septembre 4, 2020, 12:13

Le retour de :

parted -l

STP

facine41 · Septembre 4, 2020, 12:14

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:~#

facine41 · Septembre 4, 2020, 12:24

Alors, j’ai supprimé un fichier de 7Go environ, et retapé la commande df :

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…

anon70622873 · Septembre 4, 2020, 1:02

Ah ? je suppose que c’est dû au système de fichiers utilisé : BTRFS

facine41 · Septembre 4, 2020, 6:32

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 !

anon70622873 · Septembre 4, 2020, 7:52

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 »).