Full Circle Magazine FR

Cette page est en lecture seule. Vous pouvez afficher le texte source, mais ne pourrez pas le modifier. Contactez votre administrateur si vous pensez qu'il s'agit d'une erreur.
**The context identified by the title is not normal, because it obviously would be a misfit under normal circumstances. However, that situation came up when I was preparing for a future migration to another computer, expecting my current one to give up the ghost any time soon! Naturally, we try to imagine our future state and work towards that in steps, hopefully painlessly. In my case, I hit some potholes on my road to get there.

My approach here is outlined for the less experienced desktop user, but it is completely valid for server-farm context, with the one exception of the last boot step, for which server Admins would have the knowledge and skills to manipulate a live kernel using the modprobe and systemd functions to avoid a reboot.**

Le contexte identifié dans le titre n'est pas normal, parce que c'est évidemment en inadéquation dans des circonstances normales. Cependant, cette situation s'est présentée quand je préparais une migration future vers un autre ordinateur, m'attendant à ce que l'ordinateur actuel rende l'âme dans un proche avenir ! Naturellement, nous essayons d'imaginer notre état futur et de travailler dessus par étapes, de la manière la moins douloureuse possible. Dans mon cas, j'ai trouvé le chemin semé d’embûches.

Je donne un aperçu de mon approche pour l'utilisateur d'ordinateur de bureau peu expérimenté, mais c'est tout à fait valide pour un contexte serveur-réseau, exception faite de la dernière étape de redémarrage. Les admins d'un serveur auraient les connaissances et la capacité de manipuler un noyau Live avec les fonctions modprobe et systemd pour éviter un redémarrage.

**I currently have a low-end computer with 4 internal drives: 2x2TB, 1x500GB, 1x120GB. I imagined my future to be a laptop with an externally attached USB HDD, so, having had about 25 years experience with Winchester Digital drives being super reliable for myself, I bought the Winchester Digital 4TB My Book (USB 3, USB type A interface), thinking that would be a good fit. I have that USB HDD plugged in at all times. Unfortunately, my UbuntuMATE 20.04 LTS had its own ideas about that. My `uname -a` reports as: 

Linux OasisMega1 5.4.0-54-generic 
#60-Ubuntu SMP Fri Nov 6 10:37:59 UTC 2020
x86_64 x86_64 x86_64 GNU/Linux

I have used the same backup program using the rsync utility (currently v3.1.3-8) for about 8 years now, having never found the need to modify the options used. If you’re interested, have a look at Listing #1 for a batch job script that it creates for a specific task of mirroring drive /DB001_F5 to /site/DB005_F5/DB001_F5.**


Actuellement, j’ai un ordinateur de bas de gamme avec 4 disques internes : 2 x 2 To, 1 x 500 Go et 1 x 120 Go. J’imaginais un futur comportant un ordinateur portable avec un disque dur externe sur un port USB. Ainsi, connaissant les disques Winchester Digital depuis environ 25 ans et les sachant super fiables, j’ai acheté le My Book de 4 To de chez Winchester Digital (USB 3, interface USB type A), en pensant qu’il s’accorderait très bien avec le reste. Ce disque dur sur USB est toujours branché. Malheureusement, mon Ubuntu MATE 20.04 LTS avait ses propres idées le concernant. La sortie de « uname -a » est 

Linux OasisMega1 5.4.0-54-generic 
#60-Ubuntu SMP Fri Nov 6 10:37:59 UTC 2020
x86_64 x86_64 x86_64 GNU/Linux

J’utilise le même logiciel de sauvegarde avec l’utilitaire rsnyc (actuellement la v3.1.3-8) depuis environ 8 ans maintenant, sans jamais devoir modifier les options. Si cela vous intéresse, jetez un œil à Listing #1 pour le script d’un travail par lots qu’il crée pour la tâche précise de refléter le disque  /DB001_F5 vers /site/DB005_F5/DB001_F5.

**Before I go on, please note that without any system tweaks or changes, performing the backup task using tar as follows:


cd /DB001_F5 ; tar cf - . | ( cd /site/DB005_F5/DB001_F5 ; tar xvpf - )

will perform a backup onto the 4TB My Book without any problems. I have split my current and new 2/4 TB drives into 300 GB partitions for manageability (I can get into that discussion some other time).

When I try to do backup with the rsync batch script, the job hangs after a random amount of data. Sometimes it hangs immediately after creating the top-level sub-directories of the source partition, other times after about 500 files, and again sometimes after about 50 files. The filetype of the file being copied (hidden file prefixed with “.”) when it hangs appears to have no bearing on the hang/event. In one case for which I did not gather all docs, it even went so far as to completely freeze my Desktop Manager, mouse and all. NOT GOOD!**

Avant de continuer, veuillez noter que, sans modifications ni ajustements du système, une sauvegarde avec tar comme suit :

cd /DB001_F5 ; tar cf - . | ( cd /site/DB005_F5/DB001_F5 ; tar xvpf - )

mettra la sauvegarde sur le My Book de 4 To sans problèmes. J’ai partitionné mes actuels et nouveaux disques de 2/4 To en partitions de 300 Go pour pouvoir les gérer plus facilement (je peux discuter de cela une autre fois).

Quand j’essaie de faire une sauvegarde avec le script batch de rsync, la tâche s’arrête après une quantité aléatoire de données. Parfois, le travail s’arrête tout de suite après la création des sous-répertoires de haut niveau de la partition source, parfois après environ 500 fichiers et parfois après environ 50 fichiers. Le type du fichier en train d’être copié (fichier caché précédé par un « . ») quand il s’arrête ne semble pas avoir d’incidence sur l’arrêt/l’événement. Dans un cas, pour lequel je n’ai pas rassemblé tous les docs, il a même gelé le gestionnaire du bureau, y compris la souris. AFFREUX !

**From having done research (see end of article for sources), I discovered that the issue relates to the “USB Attached SCSI mode”, which was introduced with USB 3. Looking at the reference cases, I went about implementing my situational exception (referred to a “Kernel quirk” by the OS programmers).

The first step is to identify the VendorID and ProductID. The simplest method for doing this is by entering the “lsusb” command, which for me gives the result shown below.

Ayant fait des recherches (voir la fin de l’article pour mes sources), j’ai découvert que le problème est lié au « USB Attached SCSI mode », qui avait été introduit avec l’USB 3. En regardant des cas de référence, j’ai commencé à implémenter mon exception situationnelle (appelé un « Kernel quirk », une bizarrerie du noyau, par les programmeurs de l’OS).

La première étape est d’identifier l’ID du vendeur (le VendorID) et l’ID du produit (le ProductID). La façon la plus simple de le faire est d’entrer la commande « lsusb » qui me donne le résultat ci-dessous.


**As you can see, these are rarely listed in order of Bus ID #. Western Digital was very accomodating in providing a verbose and relevant identification string. The applicable line for my case is highlighted, from which the “1058:25ee” identifies 

VendorID	= 1058 and
ProductID	= 25ee

Where use of lsusb gives no definitive unique choice, the alternate method is to examine the outputs from the following command:

dmesg | grep usb

from which the segment of interest looks like that below.

Comme vous pouvez le constater, ceux-ci ne sont pas souvent listés dans l’ordre des numéros de l’ID du bus. Western Digital a gentiment fourni une chaîne d’identification pertinente et verbeuse. J’ai surligné la ligne qui s’applique à mon cas, dont le « 1058:25ee » identifie
   VendorID     = 1058 et
   ProductID    = 25ee

Là où l’utilisation de lsusb ne donne aucun choix unique et définitif, la méthode alternative est d’examiner la sortie de la commande suivante :
     dmesg | grep usb

dont la partie intéressante ressemble à ce qui se trouve en bas.

**You have to weed through the data to find the relevant items, which I have highlighted (looking for the values for each of “idVendor=” and “idProduct=”). If that is again too hard to distinguish from the dmesg report, we can force dmesg to cooperate by first powering down your drive using

udisksctl power-off -b ${BlockDevice}

where:

BlockDevice=`df ${MountPointPath} | grep /dev | awk ‘{print $1} | cut -c1-8`

then powering that up again. By doing so, all kernel messages related to the drive will be logged as one whole segregated grouping, which would look like that shown on the next page, bottom left.**

Il faut regarder attentivement les données pour trouver les éléments pertinents, que j’ai mis en valeur (en cherchant les valeurs de chacun des « idVendor= » et « idProduct= » ). Si c’est vraiment trop difficile de les distinguer dans le rapport dmesg, nous pouvons forcer dmesg à coopérer en arrêtant d’abord votre disque avec :

	udisksctl power-off -b ${BlockDevice}
où :
	BlockDevice=`df ${MountPointPath} | grep /dev | awk ‘{print $1} | cut -c1-8`

puis en le démarrant à nouveau. Ce faisant, tous les messages du noyau liés au disque seront consignés en un groupe entier distinct, qui ressemblerait à ce qui est montré à la page suivante, en bas à gauche.


**Once you have your VendorID:ProductID string, you can try to make the changes live by following the guidance hints given in reference [3], or you can do as I did, by adding the necessary quirk specification directly in my “/etc/default/grub” configuration file. Look for the line containing “GRUB_CMDLINE_LINUX_DEFAULT”, and add the quirk option as per my own line entry:

# quirk specification is to suppress UAS for external USB3 drive operating on USB2 channel.

GRUB_CMDLINE_LINUX_DEFAULT="ipv6.disable=1 usb-storage.quirks=1058:25ee:u"**


Une fois que vous avez votre chaîne VendorID:ProductID, vous pouvez essayer de rendre les modifications Live en suivant les astuces données dans la référence [3], ou vous pouvez faire comme moi en ajoutant la spécification de la quirk (bizarrerie) nécessaire directement dans le fichier de configuration « /etc/default/grub ». Cherchez la ligne qui contient « GRUB_CMDLINE_LINUX_DEFAULT » et ajoutez l’option quirk comme dans ma propre ligne :

     # spécification de la quirk pour supprimer l’UAS du disque USB3 externe qui fonctionne sur un canal USB2.
    GRUB_CMDLINE_LINUX_DEFAULT="ipv6.disable=1 usb-storage.quirks=1058:25ee:u"

**You see an extra “:u” in the option string for the quirk definition. Per reference [5], that tells the kernel to ignore the UAS option for this device’s driver. Doing it this way is, in my view, the cleanest and simplest way to implement that.

Next, remember to run “update-grub”, then (not for always-live server context) you must reboot to reinitialize the kernel.

Since having done that, my backups run smoothly with my rsync batch scripts as originally conceived. It is my hope that this clarifies what is a little understood handicap emerging from a mix of generations of technology. Naturally, once on my new computer, having a USB 3 port to match that of the HDD, that tweak in the /etc/default/grub file can be removed without consequence, being no longer required.**

Vous voyez un « :u » supplémentaire dans la chaîne de l'option pour la définition de la quirk. Comme l’indique la référence [5], cela dit au noyau d’ignorer l’option UAS pour le pilote de ce dispositif. Le faire ainsi est, je pense, la façon la plus propre et la plus simple d’implémenter cela.

Ensuite, n’oubliez pas de lancer « update-grub », puis vous devez redémarrer pour réinitialiser le noyau (cela ne concerne pas le contexte d’un serveur toujours-live).

Depuis que j’ai fait cela, mes sauvegardes avec mes scripts batch dans rsync se passent avec fluidité, comme elles ont été conçues à l’origine. J’espère que cet article clarifie ce qui est un handicap mal compris, qui émerge du mélange de générations de technologie. Bien entendu, une fois que j’aurai mon nouvel ordinateur, avec un port USB 3 qui s’accorde avec le disque dur, l’ajustement dans le fichier /etc/default/grub peut être enlevé sans problème, car il ne sera plus nécessaire.

**Listing #1 is on next page.**

Le listing numéro 1 se trouve à la page suivante.

//Bab, voici le texte en noir du listing :// OK !=)

**Listing #1 (Z_backup.DB001_F5.batch)
(run this script using command: nohup nice -n 17 ./Z_backup.DB001_F5.batch & )**

Listing N° 1 (Z_backup.DB001_F5.batch)
(exécutez ce script avec la commande : nohup nice -n 17 ./Z_backup.DB001_F5.batch & )

Références:

[1] https://en.wikipedia.org/wiki/USB_Attached_SCSI

[2] https://unix.stackexchange.com/questions/437036/odroid-xu4-hdd-dies-after-10-minutes-on-usb-3-0

[3] https://unix.stackexchange.com/questions/418326/how-do-i-make-my-seagate-2tb-usb-hdd-work-in-linux

[4] https://unix.stackexchange.com/questions/570320/usb-hard-drive-disconnecting-randomly

[5] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/admin-guide/kernel-parameters.txt?h=v4.14#n4274