Disque dur qui se remplit alors qu'il ne devrait pas

busan · 03-07-2019 13:27:06

Salut,

J'ai comme projet de monter un serveur DRBL, pour pouvoir restaurer une dizaine de poste à la volé, Pratiquement tout fonctionne, sauf un problème que j'avais avec le stockage de mes images, problème résolus dans ce post : https://debian-facile.org/viewtopic.php?id=24665, le réel problème maintenant (coucou otyugh

) c'est que malgré le faite que mon Disque Data (100 Go) se remplit et pas le Disque système (15 Go), la VM (VMware) trouve le moyen de planter, car l'espace dans le disque système est réduit à néant.

Voici grosso merdo, les commandes que j'ai fait pour en arrivé là:

apt update | apt upgrade -y

pour la forme

blkid

pour récupérer l'UUID de mon volume, ce qui donne:

/dev/mapper/vg--data-lv--data: UUID="5729f7c0-9631-4c31-9837-abc38b0255fc" TYPE="ext4"

Ensuite dans /etc/fstab, j'ai rajouté:

UUID=5729f7c0-9631-4c31-9837-abc38b0255fc /tftpboot/nbi_img ext4 defaults 0 0

ce qui donne :

# /etc/fstab: static file system information.

#

# Use 'blkid' to print the universally unique identifier for a

# device; this may be used with UUID= as a more robust way to name devices

# that works even if disks are added and removed. See fstab(5).

#

# <file system> <mount point>   <type>  <options>       <dump>  <pass>

/dev/mapper/vg--system-root /               ext4    errors=remount-ro 0       1

/dev/mapper/vg--system-swap_1 none            swap    sw              0       0

UUID=5729f7c0-9631-4c31-9837-abc38b0255fc /tftpboot/nbi_img ext4 defaults 0 0

un petit mount -a

 mount -a

puis un mount

mount

qui affiche:

sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)

proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)

udev on /dev type devtmpfs (rw,nosuid,relatime,size=983912k,nr_inodes=245978,mode=755)

devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)

tmpfs on /run type tmpfs (rw,nosuid,noexec,relatime,size=202964k,mode=755)

/dev/mapper/vg--system-root on / type ext4 (rw,relatime,errors=remount-ro,data=ordered)

securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime)

tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)

tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k)

tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755)

cgroup on /sys/fs/cgroup/unified type cgroup2 (rw,nosuid,nodev,noexec,relatime)

cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,name=systemd)

pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime)

cgroup on /sys/fs/cgroup/hugetlb type cgroup (rw,nosuid,nodev,noexec,relatime,hugetlb)

cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio)

cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset)

cgroup on /sys/fs/cgroup/rdma type cgroup (rw,nosuid,nodev,noexec,relatime,rdma)

cgroup on /sys/fs/cgroup/net_cls,net_prio type cgroup (rw,nosuid,nodev,noexec,relatime,net_cls,net_prio)

cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory)

cgroup on /sys/fs/cgroup/pids type cgroup (rw,nosuid,nodev,noexec,relatime,pids)

cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpu,cpuacct)

cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer)

cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices)

cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,nosuid,nodev,noexec,relatime,perf_event)

systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=37,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=17875)

fusectl on /sys/fs/fuse/connections type fusectl (rw,relatime)

mqueue on /dev/mqueue type mqueue (rw,relatime)

hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime,pagesize=2M)

configfs on /sys/kernel/config type configfs (rw,relatime)

debugfs on /sys/kernel/debug type debugfs (rw,relatime)

sunrpc on /run/rpc_pipefs type rpc_pipefs (rw,relatime)

nfsd on /proc/fs/nfsd type nfsd (rw,relatime)

/dev/mapper/vg--data-lv--data on /tftpboot/nbi_img type ext4 (rw,relatime,data=ordered)

lxcfs on /var/lib/lxcfs type fuse.lxcfs (rw,nosuid,nodev,relatime,user_id=0,group_id=0,allow_other)

tmpfs on /run/user/0 type tmpfs (rw,nosuid,nodev,relatime,size=202964k,mode=700)

et un

reboot

et puis je continue avec un drblpush -i

drblpush -i

dans lequel je renseigne bien "/tftpboot/nbi_img" comme répertoire de sauvegarde

Le plus étrange dans tout ça, c'est que grâce à un petit script, je peut voir en quasi temps réel le disque de data se remplir et le disque système ne rien faire.

Le script en question, on ne sait jamais.

#! /bin/bash

clear

let "i=0"

while true

do

        let "i++"

        echo $i

        df -h

        echo ""

        if [ -d "/tftpboot/nbi_img/test-4444" ];then

                echo "Le dossier1 existe !";

        else

                echo "Nope pas de fichier"

        fi

        sleep 5

        clear

done

Voilà j'espère être le plus claire possible, n'hésitez pas à me demander des informations supplémentaires.

Bonne journée,

Busan

Dernière modification par busan (03-07-2019 13:49:55)

raleur · 04-07-2019 12:46:37

A vrai dire, ce n'est pas clair pour moi. Si je lis bien, tu écris que le disque data se remplit mais pas le disque système, mais que ce dernier n'a plus d'espace libre.
Je ne comprends pas non plus la finalité de ce script ni comment il permet de voir en temps réel que le disque data se remplit.
Il vaudrait mieux montrer l'évolution de la sortie de la commande "df -h".

PS : pas besoin d'utiliser l'UUID pour identifier un système de fichiers contenu dans un volume logique, car le nom de périphérique /dev/mapper/vg-lv ou /dev/vg/lv est persistant.
PPS : éviter les tirets "-" dans les noms de VG et LV car ils sont doublés dans le nom /dev/mapper/vg-lv, c'est moche. Préférer les traits bas "_".

Dernière modification par raleur (04-07-2019 12:48:33)

busan · 04-07-2019 13:15:18

raleur a écrit :

A vrai dire, ce n'est pas clair pour moi. Si je lis bien, tu écris que le disque data se remplit mais pas le disque système, mais que ce dernier n'a plus d'espace libre.

C'est tout à fait ce qu'il se passe et c'est autant obscure pour moi que pour toi je te l'accorde .

raleur a écrit :

Je ne comprends pas non plus la finalité de ce script ni comment il permet de voir en temps réel que le disque data se remplit.

En faite toutes les 5 secondes il va afficher le résultat de la commande "df -h" et il va me dire si l'image sauvegardé est présente ou pas dans le dossier /tftpboot/nbi_img, quand au compteur du début, c'est juste pour vérifier que la machine n'est pas plantée.

Par exemple toujours dans /tftpboot/nbi_img:

Sans un fichier .ova d'environ 600Mo:

1

Filesystem                     Size  Used Avail Use% Mounted on

udev                           961M     0  961M   0% /dev

tmpfs                          199M  880K  198M   1% /run

/dev/mapper/vg--system-root     15G  5,3G  8,8G  38% /

tmpfs                          992M     0  992M   0% /dev/shm

tmpfs                          5,0M     0  5,0M   0% /run/lock

tmpfs                          992M     0  992M   0% /sys/fs/cgroup

/dev/mapper/vg--data-lv--data   98G  8,0G   85G   9% /tftpboot/nbi_img

tmpfs                          199M     0  199M   0% /run/user/0

Nope pas de fichier

Avec le fameux .ova toujours pour l'exemple:

14

Filesystem                     Size  Used Avail Use% Mounted on

udev                           961M     0  961M   0% /dev

tmpfs                          199M  880K  198M   1% /run

/dev/mapper/vg--system-root     15G  5,3G  8,8G  38% /

tmpfs                          992M     0  992M   0% /dev/shm

tmpfs                          5,0M     0  5,0M   0% /run/lock

tmpfs                          992M     0  992M   0% /sys/fs/cgroup

/dev/mapper/vg--data-lv--data   98G  8,5G   85G  10% /tftpboot/nbi_img

tmpfs                          199M     0  199M   0% /run/user/0

Nope pas de fichier

On voit donc le disque Data se remplir et pas le disque système.

raleur a écrit :

Il vaudrait mieux montrer l'évolution de la sortie de la commande "df -h".

C'est exactement ce que je fait à la ligne 11 du script.

raleur a écrit :

PS : pas besoin d'utiliser l'UUID pour identifier un système de fichiers contenu dans un volume logique, car le nom de périphérique /dev/mapper/vg-lv ou /dev/vg/lv est persistant.

Ah je savais pas merci !

Busan

Dernière modification par busan (04-07-2019 13:20:40)

Croutons · 04-07-2019 17:59:43

Hello
Je ne comprenais pas non plus
Il faut y voir quoi dans ton exemple?
Je vois que le lv data se rempli et c'est bien ce que tu veux non?

busan · 04-07-2019 18:16:16

Croutons a écrit :

Hello
Je ne comprenais pas non plus
Il faut y voir quoi dans ton exemple?
Je vois que le lv data se rempli et c'est bien ce que tu veux non?

Lv data se remplie, oui, c'est parfait et c'est ce que je veux, mais pourquoi ma Vm plante en disant que le disque système (donc pas le lv data) est plein alors qu'il est à 38% et que visiblement lui ne se remplie pas.

raleur · 04-07-2019 19:35:10

Qu'appelles-tu "ma VM" et qu'entends-tu exactement par "plante" ? Quel programme exactement affiche ce message, peux-tu le montrer ?
Ne s'agirait-il pas du système hôte ?

busan · 05-07-2019 09:53:19

raleur a écrit :

Qu'appelles-tu "ma VM"

- Ma VM: une Ubuntu server 18.04.2 (oui je sais on n'est sur debian-facile, je n'avais pas le choix), qui tourne sous du Vmware.

raleur a écrit :

qu'entends-tu exactement par "plante" ?

- le Plantage: Visiblement ma Vm refuse à un certain moment (donc quand le disque système est plein alors qu'il ne devrait pas l'être) de démarrer. Avec le message d'erreur "Votre disque nom_du_disque est plein" d'où m'a stupeur !

raleur a écrit :

Ne s'agirait-il pas du système hôte ?

Je ne pense pas, toutes les Vm sont centralisées et le stockage est géré par un SAN de plusieurs To.

Debian Alain · 05-07-2019 10:25:31

bonjour

si je peux y mettre mon grain de sel ...

je pense à un souci de buffer .

les écritures seraient faites d'abord sur le disque systeme puis transférées sur le disque de datas automatiquement .

d'où saturation du disque en cas de réemploi du mme tampon ou de transferts volumineux .

je pense , hein , suis pas un pro non plus .

busan · 05-07-2019 10:31:17

Debian Alain a écrit :

bonjour

si je peux y mettre mon grain de sel ...

je pense à un souci de buffer .

les écritures seraient faites d'abord sur le disque systeme puis transférées sur le disque de datas automatiquement .

d'où saturation du disque en cas de réemploi du mme tampon ou de transferts volumineux .

je pense , hein , suis pas un pro non plus . https://debian-facile.org/img/smilies/xtras/ops.gif

Ouais, je pensais à ça aussi, mais je ne savais pas si ce genre de fichiers existe ou pas, je vais essayer de boot sur un cd live et voir ce qu'il a dans le ventre le bougre.

Debian Alain · 05-07-2019 10:41:53

si c'est bien çà , je pense qu'il faut s'attendre à des fichiers virtuels qui ne sont pas effacés ou totalement transférés au poweroff du systeme .

d'où résidus et saturation du systeme .

la question c'est :

comment poser un diagnostic juste et fiable ?
quel(s) moyen(s) ?

comment interpréter le résultat ?
comment solutionner le problème ? (une routine ?)

glances ne pourrai pas t'aider ?

Dernière modification par Debian Alain (05-07-2019 10:48:59)

Croutons · 05-07-2019 11:00:35

hello
Il faudrait le message exact déja ça aiderait, si c'est un message de VMware il faudrait voir les ressources allouées

Debian Alain · 05-07-2019 11:34:32

tout à fait d'accord , croutons

trouvé --ceci-- .

qu'en pense la communauté ? cela peut il aider ?

Dernière modification par Debian Alain (05-07-2019 11:43:07)

raleur · 06-07-2019 09:36:54

Croutons a écrit :

Il faudrait le message exact déja ça aiderait, si c'est un message de VMware il faudrait voir les ressources allouées

Pour une fois, je pense qu'une capture d'écran s'impose.

busan · 08-07-2019 08:25:32

Salut à tous,
Alors après avoir regardé de plus près le matos, il s'avère que ma VM en particulier n'était pas sur un SAN comme dit plus haut, mais sur un disque à part donc on rajoute les 8 snapshots, le contenu des deux volumes et les images déjà présentes et paff ça fait des chocapics. Un bon coup de balais dans tout ça et c'est bon

. Bref désolé de vous avoir fait perdre votre temps avec ça.

La Bise,
Busan

Dernière modification par busan (08-07-2019 08:27:47)

Debian Alain · 08-07-2019 08:41:49

je crois te l'avoir demandé dans un autre post :
peut être peux tu nous mettre ici les retours de :

dmidecode | grep Product

inxi -F

afin de mettre un terme au fil et aussi d'alimenter la comprenette . pour partie .

Dernière modification par Debian Alain (08-07-2019 08:45:02)

busan · 08-07-2019 08:58:27

Salut Alain,

debian Alain a écrit :

peut être peux tu nous mettre ici les retours de :

root@srv-drbl:~# dmidecode | grep Product

        Product Name: VMware Virtual Platform

        Product Name: 440BX Desktop Reference Platform

et

root@srv-drbl:~# inxi -F

System:    Host: srv-drbl Kernel: 4.15.0-46-generic x86_64 bits: 64 Console: tty 0 Distro: Ubuntu 18.04.2 LTS

Machine:   Device: vmware System: VMware product: VMware Virtual Platform serial: VMware-56 4d c8 a6 f7 12 bb 0a-c3 f5 b4 b0 64 2f ff 02

           Mobo: Intel model: 440BX Desktop Reference Platform serial: N/A BIOS: Phoenix v: 6.00 date: 09/17/2015

CPU(s):    4 Single core Intel Xeon E5-2603 v2s (-SMP-) cache: 40960 KB

           clock speeds: max: 1795 MHz 1: 1795 MHz 2: 1795 MHz 3: 1795 MHz 4: 1795 MHz

Graphics:  Card: VMware SVGA II Adapter

           Display Server: N/A driver: vmwgfx tty size: 115x59 Advanced Data: N/A for root out of X

Network:   Card: VMware VMXNET3 Ethernet Controller driver: vmxnet3

           IF: ens160 state: up speed: 10000 Mbps duplex: full mac: 00:0c:29:2f:ff:02

Drives:    HDD Total Size: 125.6GB (20.5% used)

           ID-1: /dev/sdb model: Virtual_disk size: 107.4GB

           ID-2: /dev/sda model: Virtual_disk size: 18.3GB

Partition: ID-1: / size: 15G used: 5.9G (42%) fs: ext4 dev: /dev/dm-0

           ID-2: swap-1 size: 1.03GB used: 0.01GB (1%) fs: swap dev: /dev/dm-1

RAID:      No RAID devices: /proc/mdstat, md_mod kernel module present

Sensors:   System Temperatures: cpu: 100.0C mobo: N/A

           Fan Speeds (in rpm): cpu: N/A

Info:      Processes: 181 Uptime: 2 days Memory: 321.0/1982.1MB Init: systemd runlevel: 5

           Client: Shell (bash) inxi: 2.3.56

Voilà et encore

Debian-facile

#1 03-07-2019 13:27:06

Disque dur qui se remplit alors qu'il ne devrait pas

#2 04-07-2019 12:46:37

Re : Disque dur qui se remplit alors qu'il ne devrait pas

#3 04-07-2019 13:15:18

Re : Disque dur qui se remplit alors qu'il ne devrait pas

#4 04-07-2019 17:59:43

Re : Disque dur qui se remplit alors qu'il ne devrait pas

#5 04-07-2019 18:16:16

Re : Disque dur qui se remplit alors qu'il ne devrait pas

#6 04-07-2019 19:35:10

Re : Disque dur qui se remplit alors qu'il ne devrait pas

#7 05-07-2019 09:53:19

Re : Disque dur qui se remplit alors qu'il ne devrait pas

#8 05-07-2019 10:25:31

Re : Disque dur qui se remplit alors qu'il ne devrait pas

#9 05-07-2019 10:31:17

Re : Disque dur qui se remplit alors qu'il ne devrait pas

#10 05-07-2019 10:41:53

Re : Disque dur qui se remplit alors qu'il ne devrait pas

#11 05-07-2019 11:00:35

Re : Disque dur qui se remplit alors qu'il ne devrait pas

#12 05-07-2019 11:34:32

Re : Disque dur qui se remplit alors qu'il ne devrait pas

#13 06-07-2019 09:36:54

Re : Disque dur qui se remplit alors qu'il ne devrait pas

#14 08-07-2019 08:25:32

Re : Disque dur qui se remplit alors qu'il ne devrait pas

#15 08-07-2019 08:41:49

Re : Disque dur qui se remplit alors qu'il ne devrait pas

#16 08-07-2019 08:58:27

Re : Disque dur qui se remplit alors qu'il ne devrait pas

Pied de page des forums