Warren
Thanks for the thoughts. Even with 'dmesg', I
found nothing. The reboot got rid of the problem
and it continues to run perfectly in the same configuration.
I, too, have a slight dislike for external USB
disks, and much prefer internal drives for esveral reasons:
- Internal drives are protected by being inside a
tower and thus have less chance of falling or
being bumped than free-standing external boxes
- Fewer plugs and wires
- Power-up sequencing is coordinated with CPU power
- SATA3 is faster than USB3 (I think)
But sometimes one has no choice. The Mac pro may
look cute in its black cylinder, for example, but
there's no place to add anything to it. External
drives are the only choice that I know of.
David
At 07:57 AM 1/15/2018, Warren Young wrote:
On Jan 12, 2018, at 3:18 PM, david <david@xxxxxxxx> wrote:
>
> Or is it related to the annoying spin-down
and spin-up delay of external USB disks.
More likely, crap hardware, which is awfully hard to avoid in USB-land.
Just the other day, I traced a machine that
failed to reboot to an external USB
disk. Unplug it, machine boots right up. Move
the same disk to a machine as different as can
be ? different hardware, different OS, different
firmware? ? and it kernel panicâ??d that box
within about a minute of plugging it in.
in.
Then there was the time a USB enclosure ate my
data. Only the filesystemâ??s strong checksums
saved me that time. I moved the disk to another
enclosure, and the bad sector writes stopped
occurring; all else remained the same.
The problem is a market conditioned to believe
that it should expect to pay $13.64 for an
enclosure, power supply, and interface cable and
get a 5-star product. If you put a $200
enclosure in front of the vast majority of
members of that market, theyâ??d either
disbelieve the price or rate it 1 star for bad
value, even if it was guaranteed to outlast the
prevalence of the USB standard it supports, had
a higher transfer rate, and had guaranteed data
corruption rates best given in scientific
notation with large negative exponents.
Whenever I have a machine with an unkillable
userspace program, I run dtrace, and almost
always get told exactly which bit of hardware
(and therefore which kernel driver) is holding the machine hostage.
You might be able to dig the same info out of
/var/log/messages, given close-enough timestamps.
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
https://lists.centos.org/mailman/listinfo/centos
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
https://lists.centos.org/mailman/listinfo/centos
