System Update froze - UbuntuMATE 16-04

[Colin Watson]

On Sat, Jun 23, 2018 at 07:34:59AM +0800, Bret Busby wrote:
> I think it shows that no problem is evident, with the HP external HDD.

It really isn't clear to me why you think that, given all of this
distinctly abnormal output:

> [  696.354375] sd 3:0:0:0: [sdf] tag#0 FAILED Result:
> hostbyte=DID_ERROR driverbyte=DRIVER_SENSE
> [  696.354381] sd 3:0:0:0: [sdf] tag#0 Sense Key : Hardware Error
> [current] [descriptor]
> [  696.354384] sd 3:0:0:0: [sdf] tag#0 Add. Sense: No additional sense
> information
> [  696.354387] sd 3:0:0:0: [sdf] tag#0 CDB: ATA command pass
> through(16) 85 06 20 00 00 00 00 00 00 00 00 00 00 00 e5 00
> [  699.902764] sd 3:0:0:0: [sdf] tag#0 FAILED Result:
> hostbyte=DID_ERROR driverbyte=DRIVER_SENSE
> [  699.902770] sd 3:0:0:0: [sdf] tag#0 Sense Key : Hardware Error
> [current] [descriptor]
> [  699.902772] sd 3:0:0:0: [sdf] tag#0 Add. Sense: No additional sense
> information
> [  699.902776] sd 3:0:0:0: [sdf] tag#0 CDB: ATA command pass
> through(12)/Blank a1 06 20 da 00 00 4f c2 00 b0 00 00
[...]
> [  967.158490] sd 3:0:0:0: [sdf] tag#0 FAILED Result: hostbyte=DID_OK
> driverbyte=DRIVER_SENSE
> [  967.158500] sd 3:0:0:0: [sdf] tag#0 Sense Key : Medium Error [current]
> [  967.158506] sd 3:0:0:0: [sdf] tag#0 Add. Sense: Unrecovered read error
> [  967.158513] sd 3:0:0:0: [sdf] tag#0 CDB: Read(10) 28 00 08 5a 76 e8
> 00 00 f0 00
> [  967.158518] blk_update_request: critical medium error, dev sdf,
> sector 140146408

This screams "failing disk" to me.  You might temporarily be able to get
some work out of it depending on how widespread the damage is, but it's
clearly on the way out.  If this were my disk, I would:

 * order a replacement immediately if I didn't already have one on the
   shelf (it's annoying, but at least with my workloads I generally find
   that I need to budget for USB hard disks that I use for non-trivial
   amounts of data having a lifespan of only a few years - though I use
   them as cheap targets for automatic nightly backups so I tend to work
   them quite hard)

 * stop doing any further intentional writes to the disk in question

 * identify any un-backed-up data on the disk in question, and
   immediately copy as much of it as possible elsewhere; for this
   purpose I wouldn't recommend standard graphical file management
   utilities, but would instead be looking into something like gddrescue

 * once as much data as possible is backed up elsewhere, unplug the disk
   to prevent further degradation

> I think the problem lasy with the file management, due to issues with
> data transfer, causing me to previously, as I had mentioned, need to
> abort file transfers, on a number of occasions, when they has stopped
> progressing.

It's not possible for the kind of problem indicated by your descriptions
and logs to be the fault of the userspace file management utilities
you're using.

The kernel is specifically telling you in its log output that this is a
hardware error.  You should really listen to it.  Yes, strictly speaking
it's distantly conceivable that it's incorrect in reporting this, but
I'm afraid that the chances of that sort of thing are completely dwarfed
by the probability of hardware failure.

> Copying about 30-40GB of data to the USB thumb drive, took several
> hours, with the transfer rates slowing to 2MB/s, and, as low as
> hundreds of kB/s.
> 
> The USBN thumb drive was brand new, and, unused, and, is rated at 150MB/s.
> 
> Even if the transfer rate had sustained at 20MB/s, over an hour
> (3600s), it should have been able to transfer about 70MB in an hour.
> 
> But, the software does not allow that.

I haven't quite followed all of which disk is which here.  But, in
practice, when one disk attached to a system is failing, you very often
find that the I/O performance of the entire system becomes utterly
terrible because in the background the kernel is busy desperately trying
to read from or write to a device that's failing to do what it's
supposed to.  This can very easily throw off your intuition for how you
can expect the system to behave.

-- 
Colin Watson                                       [cjwatson at ubuntu.com]