[Discuss] Failing WD Disks

[bill.n1vux at gmail.com (Bill Ricker)]

On Thu, May 18, 2023 at 12:36?PM Kent Borg <kentborg at borg.org> wrote:

> Man, these disks are big. Even at (what to me seems) a crazy fast IO
>
rate, it takes a long time to traverse the disk.
>

Ayuh.
Moore's law never applied to IO or Disk cap, but similar.
Storage will likely remain just larger than IO can copy in a reasonable
period of time forever; spinning-rust rather more-so than SSD, naturally.

- Spinning media can have problems.
>

Moving parts remain problematic.
Rust as a structural component remains problematic.
Flying RW heads remain a disaster waiting to happen.
So yes, hard agree.

- Portable 5TB WD drives are maybe too bleeding edge.
>

And possibly too big to fail as well.
At 5TB size or larger, we may be better off with an array of 6+ ? 1TB disks
with redundancy, even tho that starts to cost real $$.
If the MTBF is less than a large multiple of the time to fill the disk, it
may risky to do a backup or to restore a replacement 5TB disk from backup
or from redundancy in an array!

(I remember in Web 1.0 days mid-to-late 1990's ordering a 10*G*B RAID rack
with hot-swappable drives from HP for our server for our Large Data project
-- 12 Gigs raw capacity before formatting & redundancy -- so possibly 6x2GB as
5+1 Raid ? or was it 12 x 1GB physically?  Lost to the mists of time.)

> - Even if it seems to take forever, next time I set up one of these
> disks I am going to first dd it full of random data. It will be a test
> of the disk, and makes the encrypted disk more secure.
>

Indeed.

> P.S. At least /dev/urandom, at least on my current machine, is a lot
> faster than it used to be.
>

Faster random may be less random ?
(Or just less inefficient.)
(For *testing* the disk, *cryptologically secure *random isn't required, so
fast random is ok.
But vice versa!
Whether crypto-secure random is required for cloaking the data later
written on the disk depends upon from whom you're hiding!
I can *imagine* that sorting the unused blocks from the used blocks by
statistical properties of the random fill vs the block encryption might be
useful in cracking an encrypted filesystem, but only at the margin, and if
% never used is not huge compared to % in use and % previously used but
freed, should be relatively unhelpful. And it's still better than having
0000 or DEADBEEF blocks as unused space.)

-- 
Bill Ricker
bill.n1vux at gmail.com
https://www.linkedin.com/in/n1vux