Ceci est une ancienne révision du document !
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.
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.
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!
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 hown below.
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.
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.
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”
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.
Listing #1 is on next page.
References:
[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