I am trying to back up data (230 GB, 160k files), over USB3.0 to a newly bought external Seagate Expansion Portable Drive of 4 TB, formatted as NTFS. I am running Ubuntu 18.04.3 LTS.

I first tried using a simple cp command in the terminal, but after only copying a few percent, the copying started stuttering and became slow. After some time the disk became unresponsive. Remounting the disk did not work. I tried connecting the disk to another computer, and was first unable to mount it, and then after a few attempts, it would mount but read/write would be very slow.

Once the cp starts failing, I get the following errors in dmesg (all these messages are repeating multiple times but with some different numbers):

[67598.098118] sd 4:0:0:0: [sdb] tag#18 uas_zap_pending 0 uas-tag 19 inflight: CMD 
[67598.098122] sd 4:0:0:0: [sdb] tag#18 CDB: Write(16) 8a 00 00 00 00 01 1c 75 24 18 00 00 04 00 00 00
[67598.225621] usb 1-9: reset high-speed USB device number 5 using xhci_hcd
[67598.378202] scsi host4: uas_eh_device_reset_handler success
[67598.378466] sd 4:0:0:0: [sdb] tag#14 FAILED Result: hostbyte=DID_RESET driverbyte=DRIVER_OK
[67598.378468] sd 4:0:0:0: [sdb] tag#14 CDB: Write(16) 8a 00 00 00 00 01 1c 74 d0 18 00 00 04 00 00 00
[67598.378470] blk_update_request: I/O error, dev sdb, sector 4772384792 op 0x1:(WRITE) flags 0x104000 phys_seg 128 prio class 0
[67598.378473] buffer_io_error: 246 callbacks suppressed
[67598.378474] Buffer I/O error on dev sdb2, logical block 596515075, lost async page write
[67635.212662] scsi host4: uas_eh_device_reset_handler start
[67635.213657] sd 4:0:0:0: [sdb] tag#28 uas_zap_pending 0 uas-tag 10 inflight: CMD 
[67635.213658] sd 4:0:0:0: [sdb] tag#28 CDB: Write(16) 8a 00 00 00 00 01 1c 75 e8 18 00 00 04 00 00 00
[67635.340988] usb 1-9: reset high-speed USB device number 5 using xhci_hcd
[67635.490335] scsi host4: uas_eh_device_reset_handler success

I left the disk for a week, and then did a SMART scan using the Seagate Bootable Tool, which showed no issues.

Thus, I attempted copying the data again. The disk would mount properly now and I could read/write without issues, so I started an rsync command. First I did

rsync -avh source dest

It worked, albeit slowly, for about 20 % of the data, then it started stuttering so I stopped the transfer. I restarted the transfer using

rsync -avhW source dest --inplace

to try and make it faster. It ran great, much faster than the first attempt, but after a few minutes, I received errors:

rsync: recv_generator: failed to stat "..." : Input/output error (5)
rsync: write failed on "...": Input/output error (5)
rsync error: error in file IO (code 11) at receiver.c(393) [receiver=3.1.2]

In dmesg I see the following:

[ 6772.890553] buffer_io_error: 1092735 callbacks suppressed
[ 6772.890556] Buffer I/O error on dev sdb2, logical block 874428, async page read

Once this happened, the disk became unresponsive. After a few minutes I could remount it, and checking the folder to which I was copying data it is completely empty, including the files that were properly copied during my first rsync attempt. I did not try to restore any data to see if the data was still intact, I suppose that it is only the file table that has been corrupted.

The files that were being copied at the time of failure are of type .mat.gz, on the order of 1 MB each.

As a sidenote, an old external Seagate disk recently broke when I was copying small amounts of data from it, on this computer (the infamous click of death...), which was also my first HDD ever to die.

I have no idea what to make of this, if the problem lies with how I am copying data (can copying data destroy disks?), if the problem lies with hardware (computer, HDD, USB-SATA converter, ...) or if it has to do with Ubuntu... Normally I only run Manjaro and I never experienced this kind of issues.

  • 2
    Have you run fsck or another utility to see if the HDD is actually defective? If it is, then it's not a good idea to continue to use the HDD. Jan 7, 2021 at 1:03
  • 3
    Can you provide a bit more of context from dmesg. The disk might be alright, but still it might disappear due to cables, USB bus, ... You should have some more messages related to the failure. /dev/sdb2 is the external disk, right? Jan 7, 2021 at 1:08
  • 1
    Can you install smartmontools and run a SMART check of the disk (smartctl -a /dev/sdb, or whatever device is appropriate). Look for messages saying "error" (of some sort) and attribute values Raw_Read_Error_Rate, Reallocated_Sector_Ct, Power_On_Hours, Reported_Uncorrect, Reallocated_Event_Count, Current_Pending_Sector, and Offline_Uncorrectable. Or all that table if it's easier. Jan 7, 2021 at 10:25
  • 2
    The sudden slowness might be explained if it is a shingled drive (read eg this article). It does not explain io errors, which are more likely to be due to insufficient power. Use decent short usb3 cables without any intermediate unpowered hubs.
    – meuh
    Jan 7, 2021 at 11:23
  • 2
    Check out this question and answer. They have a shingled seagate drive and are getting io errors due to enormous timeouts caused by this SMR disk architecture. They increased the timeouts and the device now works, with the usual SMR restrictions.
    – meuh
    Jan 8, 2021 at 7:28

1 Answer 1


Thank you for all your help.

I have now solved the issue. I reformatted the drive to ext4 and after that I used the command

rsync -avhW source dest --inplace --exclude=".*/"


-a is for archive, which preserves ownership, permissions etc.
-v is for verbose, to see what is happening
-h is for human-readable, so the transfer rate and file sizes are easier to read 
-W is for copying whole files only, without delta-xfer algorithm which should reduce CPU load
--inplace tells rsync to not create a temporary copy of the file to be transferred, which is then copied to the destination. This should speed up the process.
--exclude=".*/" is for excluding all hidden folders

Average data rate for 392 GB was 81.3 MB/s, which is much faster than what I achieved before reformatting the drive.

dmesg was clear of errors this time.

Note that I did not attempt to make a fresh NTFS partition on the drive to see if it was the particular NTFS paritition, from the factory, that was the problem or if it is NTFS in itself that was causing the issues. This unfortunately means that I do not have a complete answer to what the problem was. I also did not attempt to increase the timeout thresholds, but given the much faster data rate this time around, I would say that increased timeout thresholds would at best be a workaround, and not a solution.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .