J. P. Gilliver (John) wrote:
VanguardLH WROTE:
J. P. Gilliver (John) wrote:
VanguardLH WROTE:
Formatting does not erase the clusters on a hard disk.
A quick format doesn't; I think a full one does.
Nope hence the availability of utilities to rescue partitions and
files.
OK. What _does_ a non-quick format do then, that a quick one doesn't?
A full format is similar to running "chkdsk.exe /r drive:". It makes
sure all clusters are readable, not just those that are currently
allocated in the file system. That a cluster is readable does not mean
it is stable. It may be weak but just enough readable to pass the test,
like a C-grade student getting a diploma versus a straight-A student
getting one.
https://support.wdc.com/knowledgebas...r.aspx?ID=1217
Note: "files are removed" is misleading. The records for those files
are deallocated in the file system. Not even those records are wiped,
just deallocated (the clusters for those files are freed up for reuse).
Also, some files are so small (under 4K in size) that the file system
doesn't bother allocating separate clusters for those files. Instead
those files are stored right inside that 4K file record in the MFT. Why
waste clusters outside the MFT when the small file will fit inside the
file record that has the space for the file? Deallocating a file record
does not wipe the MFT file record nor wipe the clusters of the file that
are outside the MFT. "Removing" a file from the file system does not
wipe where it is stored.
More simply, Quick Format deallocates the clusters for the files while
Full Format does the same but also scans ALL sectors to look for any
that are unreadable. However, that software-based check will perform
multiple retries to overcome transient errors, plus the firmware on the
disk will perform multiple retries for each of those software-based
retries. So, in effect, a sector on the platter may get read many times
trying to return one successful read (the number of software tries times
the number of firmware tries). A long time back, I found a full format
or chkdsk /r was doing 5 retries and the drive that I had back then was
doing its own 3 retries (on each software retry), so the sector on the
platter might be tried 15 times to get 1 success for the sector to get
passed as OK. That's why I used SpinRite back then to be a better test
of not just bad sectors but also to find weak sectors. Retentivity
wanes over time (dipole stress) so a sector never rewritten, even with
the same data, will become unreliable. SpinRite has its Refresh option
to compensate for that; however, that doesn't need to be ran for many
years, and by then I've bought a newer drive that was either bigger or
used newer technology to be faster. For the price of Spinrite, I could
buy a new drive but it makes sense in a tech's toolbox that has to
support all of a company's workstations.
While I schedule "chkdsk /f drive:" on all my drives to ensure file
system integrity has not deteriorated, I only run "chkdsk /r drive:"
when I suspect problems, put in a new disk (with a partition that I'll
keep rather than do a full format), or when I'm bored and spend some
time maintaining the hardware, OS, and apps.
While you could do a low-level format on MFM and RLL drives of old, you
cannot do that with IDE or SATA drives. Those drives don't grant access
to that level of physcial control. The disk maker does their own
low-level format at the factory to find bad sectors and masks them out
in a table stored with the firmware (so the firmware knows to skip those
sectors). That is, what you get is not the maximum capacity of the disk
but something less because bad sectors got masked out so nothing can
access them. A low-level format is a physical format. The software-
based format that you do is is a logical format to place a file system
atop that physical format (and optionally scan for bad clusters which is
the allocation unit size of the file system).