Perte de la gestion de l'ordinateur.

geole · Le 01/03/2023, à 11:04

Bonjour.
Dans le contexte suivant:

cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=22.04
DISTRIB_CODENAME=jammy
DISTRIB_DESCRIPTION="Ubuntu 22.04.2 LTS"

J'éprouve, pour la première fois, le besoin de réorganiser un disque externe pour ré-agrandir une grosse partition NTFS située en fin d'un disque externe.
Pour cela, j'ai décidé d'utiliser une grosse partition NTFS située dans le disque interne contenant déjà des données.
puis de dupliquer le contenu des données par la commande RSYNC.
Constat Je perds la main au clavier. Impossible de déplacer la souris, impossible d'ouvrir une nouvelle session. Il me reste juste à attendre 2 heures que la duplication se termine.
Comme c'est la première fois que je fais cette action, je ne sais pas si cela a toujours été le cas ou si c'est une nouveauté liée à RSYNC ou au nouveau pilote NTFS.
Comme je croyais que ubuntu était multitache, je vous demande votre avis.

Ce main, je suis en train train de faire l'opération inverse. Copie depuis le disque interne vers la disque externe.
Bien sur, le fonctionnement est un petit peu ralenti ( Une certaine attente à l'ouverture d'une nouvelle session) mais je n'ai aucune difficulté à utiliser la souris et frapper ce message. Je dirais fonctionnement normal.

Donc je suis surpris que dans un sens, tout se bloque et que dans l'autre tout fonctionne....
Top pendant la copie du disque dur interne vers disque dur externe car l'inverse était impossible à faire.

Tâches: 288 total,   3 en cours, 285 en veille,   0 arrêté,   0 zombie
%Cpu(s): 11,3 ut, 20,3 sy,  0,0 ni, 49,4 id, 18,7 wa,  0,0 hi,  0,3 si,  0,0 st
MiB Mem :   5823,2 total,    393,2 libr,   2171,6 util,   3258,4 tamp/cache
MiB Éch:   1450,2 total,   1209,9 libr,    240,3 util.   2999,2 dispo Mem 

    PID UTIL.     PR  NI    VIRT    RES    SHR S  %CPU  %MEM    TEMPS+ COM.     
   8382 root      20   0   15656   6076   1804 S  49,0   0,1  10:01.12 mount.n+ 
     61 root      20   0       0      0      0 S  22,2   0,0   7:13.69 kswapd0  
   8410 a         20   0   19980   4884   1532 S  13,2   0,1   2:46.75 rsync    
   2079 a         20   0 5650628 242560  65476 S   9,3   4,1   4:10.83 gnome-s+ 
    919 root      20   0   15816   6128   1716 D   8,3   0,1  16:06.81 mount.n+ 
   8408 a         20   0   20328   7208   3752 R   7,6   0,1   1:37.05 rsync    
   3758 a         20   0   11,6g 255708  74904 S   4,6   4,3   2:37.10 firefox  
   4635 a         20   0 2884668  92756  50040 S   3,3   1,6  10:52.60 Isolate+ 
   3627 a         20   0  837344  47436  33040 S   1,3   0,8   0:20.80 gnome-t+ 
   4061 a         20   0  408756  48132   9040 S   0,7   0,8   0:17.35 Xwayland 
   5207 root      20   0       0      0      0 D   0,7   0,0   0:46.19 usb-sto+ 
  11069 root      20   0       0      0      0 R   0,7   0,0   0:02.77 kworker+ 
  11110 a         20   0   15980   4332   3384 R   0,7   0,1   0:00.06 top      
     60 root       0 -20       0      0      0 I   0,3   0,0   0:03.40 kworker+ 
    194 root       0 -20       0      0      0 I   0,3   0,0   0:03.05 kworker+ 
   7472 root      20   0       0      0      0 I   0,3   0,0   0:00.81 kworker+ 
      1 root      20   0  167748  10084   5396 S   0,0   0,2   0:05.39 systemd

a@p:~$ df -BG  | egrep "Mont|Commun"
Sys. de fichiers blocs de 1G Utilisé Disponible Uti% Monté sur
/dev/sda17              396G    366G        30G  93% /media/Commun
/dev/sdb2               496G    469G        28G  95% /media/a/Commun-SAVE
a@p:~$

Apparté Pour ceux qui utilisent des partitions NTFS sans disposer de windows:
Pendant la première opération, la partition du disque interne s est trouvée pleine, Gparted a refusé de l'agrandir. J'ai du utiliser windows

Agrandir /dev/sda17 de 287.37 Gio à 395.71 Gio  00:00:14    ( ERREUR )
     	
calibrer /dev/sda17  00:00:07    ( SUCCÈS )
     	
chemin : /dev/sda17 (partition)
début : 1123670016
fin : 1726318591
taille : 602648576 (287.37 Gio)
vérifier le système de fichiers sur /dev/sda17 et corriger les problèmes (si possible)  00:00:07    ( ERREUR )
     	
ntfsresize -i -f -v '/dev/sda17'  00:00:07    ( ERREUR )
     	
ntfsresize v2021.8.22 (libntfs-3g)
Device name : /dev/sda17
NTFS volume version: 3.1
Cluster size : 4096 bytes
Current volume size: 308556067328 bytes (308557 MB)
Current device size: 308556070912 bytes (308557 MB)
Checking for bad sectors ...
Checking filesystem consistency ...
100.00 percent completed
Accounting clusters ...
Space in use : 308557 MB (100,0%)
Collecting resizing constraints ...
ERROR: Volume is full. To shrink it, delete unused files.

Coeur Noir · Le 01/03/2023, à 15:08

Hello,

[ plutôt HS ]
d'abord : rien d'étonnant à « Gparted a refusé de l'agrandir. J'ai du utiliser Windows »
NTFS est un produit Microsoft et seuls les outils Microsoft savent complètement le gérer.
C'est d'ailleurs pour ça qu'on recommande souvent de s'occuper des partitions NTFS depuis Windows.
D'autres système de fichiers compatibles Microsoft ont fait l'objet de publication de leurs spécifications, mais pas le NTFS, chasse gardée :
ce que les développeurs en savent provient de rétro-ingénierie, et non de spécifications qui auraient été officiellement fournies par Microsoft.
Donc dans certaines situations, Gparted ne fera pas de miracle avec du NTFS.
[ fin HS ]

Ensuite… j'ai aussi déjà vu des différences de comportement / vitesse selon les supports, leur « sens » ( interne ↔ externe ), leur connexion ( usb1,2,3 ) mais pas au point de ralentir / bloquer la session.
Mais c'est matériel : des bus ou contrôleurs peu performants, des hubs qui font goulet d'étranglement, des câbles ou prises en mauvais état, ça tient à pas grand' chose des fois !

Pourquoi as-tu utilisé la commande rsync à cet endroit et ce moment là ?
Pour la première copie des données je pense qu'un cp aurait suffi.
Et peut-on voir ta commande rsync - des fois qu'une de ses options expliquerait ce comportement plutôt gênant ?

Dernière modification par Coeur Noir (Le 01/03/2023, à 15:10)

Astrolivier · Le 01/03/2023, à 15:22

salut,

peut-être une histoire de montage
https://askubuntu.com/questions/520992/ … mount-ntfs

tu as mount.n+ qui prend beaucoup de cpu. peut être en jouant avec les options dans fstab (big_writes) comme dans le -vieux - post ci dessus, mais je ne trouve rien sur mount.n+.
ça n'a pas l'air d'être très nouveau comme problème. j’utilise pas de ntfs mais ça m'arrivait souvent d'avoir le proc qui bosse à fond en faisant des copies avec mon ancien ordi (que j'ai gardé 12 ans !). des fois en changeant de port usb ça allait mieux, des fois c'est plus mystérieux. le sens comptait aussi.

geole · Le 02/03/2023, à 09:21

Bonjour.
Je n'ai pas retrouvé la commande exécutée

a@p:~$ history  | grep  rsync
  373  man rsync
  379  if [[ $A  =~  "/media/$USER/$LABEL-Janvier " ]]; then echo Lançons la synchronisation.; time rsync dry-run -av --stats --delete-after --progress /media/$LABEL/* /media/$USER/$LABEL-SAVE; else echo "Le disque externe  n'est pas bien monté. La synchronisation  n'est pas lancée."; fi
  381  if [[ $A  =~  "/media/$USER/$LABEL-SAVE " ]]; then echo Lançons la synchronisation.; time rsync --dry-run -av --stats --delete-after --progress /media/$LABEL/* /media/$USER/$LABEL-SAVE; else echo "Le disque externe  n'est pas bien monté. La synchronisation  n'est pas lancée."; fi
  457  man rsync
  465  if [[ $A  =~  "/media/$USER/$LABEL-SAVE " ]]; then echo Lançons la synchronisation.; time rsync --dry-run -av --stats --delete-after --progress --backupr --backup-dir=/media/$USER/$LABEL-SAVE/PouBelle --exclude PouBelle /media/$LABEL/* /media/$USER/$LABEL-SAVE
  467  if [[ $A  =~  "/media/$USER/$LABEL-SAVE " ]]; then echo Lançons la synchronisation.; time rsync --dry-run -av --stats --delete-after --progress --backup --backup-dir=/media/$USER/$LABEL-SAVE/PouBelle --exclude PouBelle /media/$LABEL/* /media/$USER/$LABEL-SAVE; else echo "Le disque externe  n'est pas bien monté. La synchronisation  n'est pas lancée."; fi
  473  if [[ $A  =~  "/media/$USER/$LABEL-SAVE " ]]; then echo Lançons la synchronisation.; time rsync -av --stats --delete-after --progress -b --backup-dir=/media/$USER/$LABEL-SAVE/PouBelle --exclude PouBelle /media/$LABEL/* /media/$USER/$LABEL-SAVE; else echo "Le disque externe  n'est pas bien monté. La synchronisation  n'est pas lancée."; fi
  497  if [[ $A  =~  "/media/$USER/$LABEL-SAVE " ]]; then echo Lançons la synchronisation.; time rsync -av --stats --delete-after --progress -b --backup-dir=/media/$USER/$LABEL-SAVE/PouBelle --exclude PouBelle /media/$LABEL/* /media/$USER/$LABEL-SAVE; else echo "Le disque externe  n'est pas bien monté. La synchronisation  n'est pas lancée."; fi
  501  history  | grep  rsync
a@p:~$

mais elle devait être celle-ci

 rsync -av --stats --progress    /media/$USER/$LABEL-SAVE/*  /media/$LABEL

mais, à la réflexion, elle a été celle-ci.

a@p:~$ history  | grep  cp 
  394  cp -ruv /media/$USER/$LABEL-SAVE/Rugby* /media/$LABEL
  451  cp -ruv /media/$USER/$LABEL-SAVE/Rugby* /media/$LABEL
  455  cp -ruv /media/$USER/$LABEL-SAVE/Rugby* /media/$LABEL
  503  history  | grep  cp

Je m'en souviens maintenant. Après avoir perdu la main, j'avais rebooté puis relancé. Comme j'ai de nouveau perdu la main, j'ai pensé que la commande état en cause. Totalement oublié que je n'avais pas exceptionnellement utilisé RSYNC! Dommage que je ne sache pas trouver les dates des commandes.
Donc la piste de saturation en écriture du disque serait en cause avec la commande cp. Les fichiers copiés avaient en moyenne une taille de 500 Mo.

Astrolivier · Le 03/03/2023, à 00:16

https://www.cyberciti.biz/faq/unix-linu … date-time/

echo 'export HISTTIMEFORMAT="%d/%m/%y %T "' >> ~/.bash_profile

source ~/.bash_profile

geole · Le 03/03/2023, à 00:36

Bonsoir Astrolivier.
Je note dans mes tablettes qu'il y avait bien une préparation à faire. Dommages que cela pas incorporé de base.

Astrolivier · Le 03/03/2023, à 02:13

sans toi j'aurais jamais pensé à regarder, et j'ai trouvé vite fait.

c'est une bonne manière pour moi de fouiner dans le bash que je connais peu !
c'est vrai qu'une option pour ça aurait été bienvenue, ça doit se coder sans trop de difficulté puisque la variable existe

iznobe · Le 10/04/2024, à 14:41

Bonjour geole , je suis aussi de l ' avis d ' Astrolivier : le processus mount.ntfs ? + ?? consomme bien trop de ressources CPU :

    PID UTIL.     PR  NI    VIRT    RES    SHR S  %CPU  %MEM    TEMPS+ COM.     
   8382 root      20   0   15656   6076   1804 S  49,0   0,1  10:01.12 mount.n+

pas normal , faut verifier les options de montages ou si un bug existe a ce propos .

Dernière modification par iznobe (Le 10/04/2024, à 14:41)

Coeur Noir · Le 10/04/2024, à 15:33

Pour aller dans le même sens qu'Iznobe, comme tu as parfois testé le pilote « noyau » NTFS3, reviens peut-être au « vieux » pilote ( les paquets libntfs-3g89 et ntfs-3g ) ?

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1 Le 01/03/2023, à 11:04

Perte de la gestion de l'ordinateur.

#2 Le 01/03/2023, à 15:08

Re : Perte de la gestion de l'ordinateur.

#3 Le 01/03/2023, à 15:22

Re : Perte de la gestion de l'ordinateur.

#4 Le 02/03/2023, à 09:21

Re : Perte de la gestion de l'ordinateur.

#5 Le 03/03/2023, à 00:16

Re : Perte de la gestion de l'ordinateur.

#6 Le 03/03/2023, à 00:36

Re : Perte de la gestion de l'ordinateur.

#7 Le 03/03/2023, à 02:13

Re : Perte de la gestion de l'ordinateur.

#8 Le 10/04/2024, à 14:41

Re : Perte de la gestion de l'ordinateur.

#9 Le 10/04/2024, à 15:33

Re : Perte de la gestion de l'ordinateur.

Pied de page des forums