On Sun, 09 Aug 2020 01:44:20 -0400, Flasherly
wrote:

Of course the HDD has not, per se, been written to since the check
disk routine, only copied from and to the SDD.

--

Another aspect, since static storage is for the most achievable, are
software defragmention routines.

Prior and at some point over a course of the last two or three
motherboard updates, I began to notice decided lags during
defragmentation. An earlier SATA hardware controller implementation,
both on motherboard controllers and PCI HDD controllers, were
straight-forward, progressively visible manifestations within if not
nearer to copy/write, at expected speeds. That particular motherboard
had but two SATA ports (and a PCI SATA controller for a sum four SATA
connections).

I haven't longer the indulgence of PCI slots in a present stasis of,
usually one slot, budget micro-motherboard factors;- nor are added
controllers necessarily the budget price consideration of under $10US
controllers before.

Indulgence, however, is neither being constrained by a single HDD,
more frequently for modified files to occur to subsequently defrag,
since alternatives since include a supplemental larger SSD to move
instances of modification from the HDD and to the SSD. Although it
not is not quite the indulgence, at times and within deframentation
approaches, similar but exacted, up to extended file copies, if needed
across the whole of a drive, that result in alphabetical file
orderings (within a greater result, per se without fragmentation,
resulting of non-fragmented files from a file copy/write routine).

The software defragmentation routines, however, are not now buffered
as smoothly as former PCI controllers. Timing is resultantly extended,
whereas actual copy/write manipulations, which would not exhibit speed
deterioration, is the preferable recourse to, without exception, to
say copying near 2T of data, in hours, versus similarly defragmenting
that structure over an incredulous course of actual days.

A given limitation, as it is, that deframentation so engaged is to be
within limited fewer instances, which do result from files
defragmented, upon copy/writing them, such to only run defragmentation
on those specific files, with disdain for other than the perfunctory
result of singular unity. Any larger degree of fragmentation, apart
of altogether being avoided, (a HDD stasis and the supplemental SSD
augments to circumvent), would be addressed by a re-copy, possibly
with a initial format of the drive, only customarily to address what
few files do fragment during the copy, and, in the case of the SMART
errors perhaps specific to questionable drive media mentioned before,
such that a low-level ChkDsk routine is then successfully run,
hopefully to reestablish continued stasis for stability across
long-term database reads. A ChkDisk capable of going beyond to address
sectors differentially by time would be interesting if it existed.

One further yet is the implication of extended framgmentation
manipulation of so-addressed routines as desirable, indeed if not
deleteriously to factor from newer instances of implemented
controllers, indeed to precipitate not all may fail so abjectly, which
strangely do not fault into "churning" episodes, as wholly do all
deframentators I have -- wholly, that is, absent from all instances of
programs which but copy and write. A deframenter to be suspect of
added usage for prematurely wearing down drives with excessive
churning may seem a damning indictment. But is it. . .HDDs no longer
have a sole impetus upon storage from a shift, from ten years ago, as
NAND SSD storage is seen in its two implementations, past SATA, as
directly accountable for motherboard implementation of storage much as
slotted memory.

Strange as it may seem, I've actually seen instances for future design
implementation, abnegating the SATA factor, altogether a PATA interim
patchwork, much as was ISA superfluously rendered obsolete by PCI.