Hey,
I just bought a Seagate Expansion Portable 2TB. When copying files to it With Nautilus or Dejà Dup it works just fine (tried copying a folder with ≥20GB of misc. files and compared checksums – no problem) with the speed of about 30MB/s, running on a Thinkpad X220 USB2 port.
The problem is when I use rsync
or dd
, the speed drops drastically after a little while, almost freezing, and the dmesg output is filled with various UAS and I/O errors.
Example output:
nov 23 16:06:21 jurajov-thinkpad kernel: sd 6:0:0:0: [sdc] tag#27 uas_eh_abort_handler 0 uas-tag 16 inflight: CMD
nov 23 16:06:21 jurajov-thinkpad kernel: sd 6:0:0:0: [sdc] tag#27 CDB: Write(10) 2a 00 10 07 f0 40 00 02 00 00
If it’s just these, it usually recovers, usually within several (max. tens of) minutes. If I’m trying to write/copy too much, things like this start happening:
nov 23 16:02:27 jurajov-thinkpad kernel: Buffer I/O error on dev sdc1, logical block 33635348, lost async page write
nov 23 16:02:27 jurajov-thinkpad kernel: Buffer I/O error on dev sdc1, logical block 33635349, lost async page write
nov 23 16:02:27 jurajov-thinkpad kernel: Buffer I/O error on dev sdc1, logical block 33635350, lost async page write
nov 23 16:02:27 jurajov-thinkpad kernel: blk_update_request: I/O error, dev sdc, sector 269083304 op 0x1:(WRITE) flags 0x4800 phys_seg 64 prio class 0
nov 23 16:02:27 jurajov-thinkpad kernel: blk_update_request: I/O error, dev sdc, sector 269083816 op 0x1:(WRITE) flags 0x800 phys_seg 22 prio class 0
nov 23 16:02:27 jurajov-thinkpad kernel: blk_update_request: I/O error, dev sdc, sector 269084440 op 0x1:(WRITE) flags 0x800 phys_seg 36 prio class 0
Unmounting the harddrive at this point is useless – I tried waiting several hours, it didn’t finish.
My research suggests falling back to the usb-storage
driver. But that just seems like a hack. AFAIK Linux already special-cases all Seagate enclosures; shouldn’t this be reported as a kernel bug? And what is the problem even, if Nautilus and the like operate just fine?
The weirdest thing is that this states that the already-present quirk is not needed on this model, stating a kernel developer (which is true – disabling it fixes S.M.A.R.T. access. It even goes as far as to claim this drive does not have any firmware bugs.
I’m thinking about selling the drive and buying another one.