#1 Le 01/03/2023, à 11:04
- geole
Perte de la gestion de l'ordinateur.
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.
Les grilles de l'installateur https://doc.ubuntu-fr.org/tutoriel/inst … _subiquity
"gedit admin:///etc/fstab" est proscrit, utilisez "pkexec env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY xdg-open /etc/fstab" Voir https://doc.ubuntu-fr.org/gedit
Les partitions EXT4 des disques externes => https://forum.ubuntu-fr.org/viewtopic.p … #p22697248
Hors ligne
#2 Le 01/03/2023, à 15:08
- Coeur Noir
Re : Perte de la gestion de l'ordinateur.
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)
Débuter ⋅ Doc ⋅ Bien rédiger ⋅ Retour commande ⋅ Insérer image | illustrations & captures d'écran < ⋅ >
Hors ligne
#3 Le 01/03/2023, à 15:22
- Astrolivier
Re : Perte de la gestion de l'ordinateur.
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.
S'il faut absolument faire des sacrifices pour assurer le progrès de l'humanité, ne serait-il pas indispensable de s'en tenir au principe selon lequel c'est à ceux dont on exige le sacrifice que la décision doit revenir en dernier ressort ? (howard zinn)
Hors ligne
#4 Le 02/03/2023, à 09:21
- geole
Re : Perte de la gestion de l'ordinateur.
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.
Les grilles de l'installateur https://doc.ubuntu-fr.org/tutoriel/inst … _subiquity
"gedit admin:///etc/fstab" est proscrit, utilisez "pkexec env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY xdg-open /etc/fstab" Voir https://doc.ubuntu-fr.org/gedit
Les partitions EXT4 des disques externes => https://forum.ubuntu-fr.org/viewtopic.p … #p22697248
Hors ligne
#5 Le 03/03/2023, à 00:16
- Astrolivier
Re : Perte de la gestion de l'ordinateur.
https://www.cyberciti.biz/faq/unix-linu … date-time/
echo 'export HISTTIMEFORMAT="%d/%m/%y %T "' >> ~/.bash_profile
source ~/.bash_profile
S'il faut absolument faire des sacrifices pour assurer le progrès de l'humanité, ne serait-il pas indispensable de s'en tenir au principe selon lequel c'est à ceux dont on exige le sacrifice que la décision doit revenir en dernier ressort ? (howard zinn)
Hors ligne
#6 Le 03/03/2023, à 00:36
- geole
Re : Perte de la gestion de l'ordinateur.
Bonsoir Astrolivier.
Je note dans mes tablettes qu'il y avait bien une préparation à faire. Dommages que cela pas incorporé de base.
Les grilles de l'installateur https://doc.ubuntu-fr.org/tutoriel/inst … _subiquity
"gedit admin:///etc/fstab" est proscrit, utilisez "pkexec env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY xdg-open /etc/fstab" Voir https://doc.ubuntu-fr.org/gedit
Les partitions EXT4 des disques externes => https://forum.ubuntu-fr.org/viewtopic.p … #p22697248
Hors ligne
#7 Le 03/03/2023, à 02:13
- Astrolivier
Re : Perte de la gestion de l'ordinateur.
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
S'il faut absolument faire des sacrifices pour assurer le progrès de l'humanité, ne serait-il pas indispensable de s'en tenir au principe selon lequel c'est à ceux dont on exige le sacrifice que la décision doit revenir en dernier ressort ? (howard zinn)
Hors ligne
#8 Le 10/04/2024, à 14:41
- iznobe
Re : Perte de la gestion de l'ordinateur.
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)
retour utilisable de commande
MSI Z490A-pro , i7 10700 , 32 GB RAM .
En ligne
#9 Le 10/04/2024, à 15:33
- Coeur Noir
Re : Perte de la gestion de l'ordinateur.
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 ) ?
Débuter ⋅ Doc ⋅ Bien rédiger ⋅ Retour commande ⋅ Insérer image | illustrations & captures d'écran < ⋅ >
Hors ligne