[OMV]: Redimensionner partition système Le sujet est résolu

Demande d'aide : c'est ici.
Répondre
Avatar du membre
genpashiro
Membre
Membre
Messages : 122
Enregistré le : 25 sept. 2018, 15:07
Localisation : Douai, Nord
Status : Hors ligne

18 oct. 2020, 13:15

:006:

J'ai un NAS maison sous OMV, lors de l'installation, il a été alloué ~9Gib pour la partition système mais je m'aperçois que celle-ci est déjà bientôt utilisée en entier!

J'ai mis les autres DD en LVM, est-il possible de prendre de l'espace disque du LVM pour agrandir la partition système ?? :icon_question:

Je mets en PJ quelques screenshot des DD

https://jirafeau.leblais.net/f.php?h=0LRL9LXK&p=1

https://jirafeau.leblais.net/f.php?h=3bkQe07t&p=1

https://jirafeau.leblais.net/f.php?h=3TTXEB4-&p=1

https://jirafeau.leblais.net/f.php?h=1mFVdMxZ&p=1
Avatar du membre
dezix
Modérateur
Modérateur
Messages : 1119
Enregistré le : 04 juin 2016, 14:50
Diaspora* : dezix@framasphere.org
Status : Hors ligne

18 oct. 2020, 13:29

Salut,

tu peux nous faire un petit :

# lsblk

pour y voir plus clair, merci
Debian testing/stable - XFCE
Avatar du membre
genpashiro
Membre
Membre
Messages : 122
Enregistré le : 25 sept. 2018, 15:07
Localisation : Douai, Nord
Status : Hors ligne

18 oct. 2020, 13:38

Code : Tout sélectionner

NAME        MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda           8:0    0 149.1G  0 disk 
├─sda1        8:1    0    10G  0 part /
├─sda2        8:2    0     1K  0 part 
├─sda3        8:3    0 136.4G  0 part 
│ └─nas-NAS 254:0    0   3.6T  0 lvm  /srv/dev-disk-by-id-dm-name-nas-NAS
└─sda5        8:5    0   2.8G  0 part [SWAP]
sdb           8:16   0 149.1G  0 disk 
└─sdb1        8:17   0 149.1G  0 part 
  └─nas-NAS 254:0    0   3.6T  0 lvm  /srv/dev-disk-by-id-dm-name-nas-NAS
sdc           8:32   0 149.1G  0 disk 
└─sdc1        8:33   0 149.1G  0 part 
  └─nas-NAS 254:0    0   3.6T  0 lvm  /srv/dev-disk-by-id-dm-name-nas-NAS
sdd           8:48   0 931.5G  0 disk 
└─sdd1        8:49   0 931.5G  0 part 
  └─nas-NAS 254:0    0   3.6T  0 lvm  /srv/dev-disk-by-id-dm-name-nas-NAS
sdj           8:144  0 931.5G  0 disk 
└─sdj1        8:145  0 931.5G  0 part 
  └─nas-NAS 254:0    0   3.6T  0 lvm  /srv/dev-disk-by-id-dm-name-nas-NAS
sdk           8:160  0   1.4T  0 disk 
└─sdk1        8:161  0   1.4T  0 part 
  └─nas-NAS 254:0    0   3.6T  0 lvm  /srv/dev-disk-by-id-dm-name-nas-NAS
sr0          11:0    1  1024M  0 rom  
sr1          11:1    1  1024M  0 rom  
Avatar du membre
dezix
Modérateur
Modérateur
Messages : 1119
Enregistré le : 04 juin 2016, 14:50
Diaspora* : dezix@framasphere.org
Status : Hors ligne

18 oct. 2020, 15:36

sda2 de 1ko te sert à quoi ?

Où as-tu de l'espace disponible (de préférence sur sda) ?

Dommage que tu n'ais pas la swap devant sda3 , tu aurais pu mettre la swap sur un LV et récupérer tout le début du sda pour le système.

Pour les histoires de NAS, je n'y connais RIEN,
mais si tu peux créer des LV quelque-part,
alors il est simple d'y déplacer des sous-répertoires de / (p.ex /usr ; /var)
et de modifier ton /etc/fstab pour indiquer les nouvelles associations partition/point de montage

Remarque, tu peux aussi si tu déplaces la swap, crée une part ext4 sur ses 2.8Go pour /usr

Que donne : # du -sh /usr

Attends les avis de ceux qui connaissent NAS avant de tenter ... Prudence ! :wink:
Debian testing/stable - XFCE
PascalHambourg
Contributeur
Contributeur
Messages : 442
Enregistré le : 05 août 2016, 20:25
Status : Hors ligne

18 oct. 2020, 19:25

Je soupçonne que sda2 est une partition étendue qui contient la partition logique de swap sda5. Dans ce cas il est plausible que ces deux partitions soient situées entre la partition racine sda1 et la partition LVM sda3, et il serait possible de les supprimer pour agrandir la partition racine. On ne peut le vérifier qu'en examinant la table de partition de sda avec fdisk ou autre. Ensuite il faudra recréer un swap ailleurs, par exemple en tant que un volume logique.

2,8 Go ne seraient pas forcément suffisants pour /usr car c'est normalement ce qui prend le plus d'espace dans la racine. Néanmoins déporter une partie du contenu de la racine dans un autre système de fichiers (partition ou volume logique) est une option envisageable, selon l'espace occupé par les différents répertoires.

Code : Tout sélectionner

du -hxd1 / | sort -h
Les copies d'écran ne sont pas très utiles, il vaudrait mieux des sorties de commandes en console.

Code : Tout sélectionner

du -hxd1 / | sort -h
fdisk -l
lvs
vgs
pvs
Avatar du membre
genpashiro
Membre
Membre
Messages : 122
Enregistré le : 25 sept. 2018, 15:07
Localisation : Douai, Nord
Status : Hors ligne

18 oct. 2020, 20:07

Merci pour ton aide :

Code : Tout sélectionner

 du -hxd1 / | sort -h 
4.0K	/export
4.0K	/home
4.0K	/lib64
4.0K	/sharedfolders
8.0K	/recovery
12K	/media
12K	/mnt
12K	/sftp
12K	/srv
16K	/lost+found
160K	/opt
208K	/root
7.8M	/etc
14M	/bin
15M	/sbin
96M	/boot
763M	/lib
888M	/usr
5.5G	/var
7.3G	/

Code : Tout sélectionner

lvs :
LV   VG  Attr       LSize Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert
  NAS  nas -wi-ao---- 3.61t   

vgs :
VG  #PV #LV #SN Attr   VSize VFree
  nas   6   1   0 wz--n- 3.61t    0 

pvs:
PV         VG  Fmt  Attr PSize   PFree
  /dev/sda3  nas lvm2 a--  136.36g    0 
  /dev/sdb1  nas lvm2 a--  149.05g    0 
  /dev/sdc1  nas lvm2 a--  149.05g    0 
  /dev/sdd1  nas lvm2 a--  931.48g    0 
  /dev/sdj1  nas lvm2 a--  931.51g    0 
  /dev/sdk1  nas lvm2 a--    1.36t    0 
pour reprendre la commande de @dezix, je vois que presque tout l'espace disque est occupé par les logs :

Code : Tout sélectionner

du -sh /var/log 
4.9G	/var/log
Avatar du membre
dezix
Modérateur
Modérateur
Messages : 1119
Enregistré le : 04 juin 2016, 14:50
Diaspora* : dezix@framasphere.org
Status : Hors ligne

18 oct. 2020, 20:14

Je crois que tu vas avoir une solution assez simple en faisant le ménage dans /var/log
Debian testing/stable - XFCE
Avatar du membre
genpashiro
Membre
Membre
Messages : 122
Enregistré le : 25 sept. 2018, 15:07
Localisation : Douai, Nord
Status : Hors ligne

18 oct. 2020, 20:22

dezix a écrit :
18 oct. 2020, 20:14
Je crois que tu vas avoir une solution assez simple en faisant le ménage dans /var/log
pour éviter de faire le ménage manuellement, on peut mettre en place des logs non archivés non ?
Avatar du membre
genpashiro
Membre
Membre
Messages : 122
Enregistré le : 25 sept. 2018, 15:07
Localisation : Douai, Nord
Status : Hors ligne

18 oct. 2020, 20:44

bon avec un truncate -S 0 ça réduit bien !

du -sh /var/log
20M /var/log

mais bon ça n'est pas viable sur le long terme, un redimensionnement serait la solution.
Avatar du membre
dezix
Modérateur
Modérateur
Messages : 1119
Enregistré le : 04 juin 2016, 14:50
Diaspora* : dezix@framasphere.org
Status : Hors ligne

18 oct. 2020, 21:01

J'ai encore tout à apprendre dans la gestion des logs,
mais il me semble avoir lu qu'il y a des outils pour maintenir les logs dans un espace pré-configuré.
Regarde p.ex : logrotate

C'est à mon programme d'apprentissage, mais je n'y suis pas encore :((
Debian testing/stable - XFCE
PascalHambourg
Contributeur
Contributeur
Messages : 442
Enregistré le : 05 août 2016, 20:25
Status : Hors ligne

18 oct. 2020, 21:12

genpashiro a écrit :
18 oct. 2020, 20:22
pour éviter de faire le ménage manuellement, on peut mettre en place des logs non archivés non ?
Qu'entends-tu exactement par "logs non archivés" ?
Normalement logrotate est installé et configuré par défaut pour "faire tourner" les logs, compresser les anciens et effacer les plus anciens. 5 Go de logs, c'est anormal.
genpashiro a écrit :
18 oct. 2020, 20:44
bon avec un truncate -S 0 ça réduit bien !
Et ça détruit les indices aussi.
Soit il y a eu un événement ponctuel qui a généré un énorme volume de logs et ça suffit, soit la cause des logs abondants persiste et le problème va revenir. Mais pour le déterminer, il faut examiner les logs, pas les effacer.
Avatar du membre
genpashiro
Membre
Membre
Messages : 122
Enregistré le : 25 sept. 2018, 15:07
Localisation : Douai, Nord
Status : Hors ligne

24 oct. 2020, 15:21

"Archivés" n'est pas le bon terme en effet.

Les logs étaient pourtant bien en gz donc compressés.

Je continue à surveiller la taille de ces logs. Il y a peut être un service installé qui est peut être trop verbeux....

Merci pour vos aides!
Répondre