[EdLUG] mounting name adjustment & personal

[Edinburgh Linux Users Group]

Thanks for the info Dee

As the other poster mentioned (anonymous because we're still trying to
resolve an issue fighting off automated abusive responder bots), it seems
like the operational modes of the disks you are referring to are different
from those in current consumer goods.

If there are any specific models of disks you are testing against it would
be of relevance to know. Have you been documenting this in blog for
anywhere perchance? Then interested parties could read up further on your
findings

All the best

Tai



===
Tai Kedzierski

Affordable Office IT for Freelance and Startup Businesses
http://helpuse.com/

  I use www.libreoffice.org

*Open Source Free Software is a matter of liberty, not price.*
http://bit.ly/foss-why-care


On 25 May 2016 at 19:44, Edinburgh Linux Users Group <
edlug at lists.edlug.org.uk> wrote:

> On 2016.05.25 10:49, Edinburgh Linux Users Group wrote:
> > Hellow edlug.org
> >
> > Attn:  Tai Kedzierski
> >
>
> Dee,
>
> >
> [snip]
> >
> > The drive heads race back and forth from one part of the data sets
> > that belong to the A/R system. This beating of air in the drive
> > heats the air and then the drive.
> >
> > If all the A/R component data files are in the same partition as
> > the final print A/R file, then writing the print file will have
> > a risk if the A/R operation goes on for more than 5 to 10 minuets.
> >
> > As the drive warms up the thermal compensation can be exceeded for
> > that drive. The head(s) no longer are centred on the data track
> > but now straddle the data and the guard band. In Windows the write
> > update is in the outer tracks where the thermal expansion is most.
> >
> > Also the head(s) write deeper into warm magnetic surface and that
> > takes more write energy to penetrate to erase any hot write. The
> > new data is partly on the data track and partly on the guard band.
> >
> > When the drive cools a bit the heads are again centred on the data
> > track but reading part of the old bit and part of the new bit.
>
> That's an interesting theory.
> >
> > The outer data tracks index the location of the data further in
> > from the rim of the drive. But bad sectors are reported as the
> > index information is ambiguous.
>
> This was true when hard drives used the same mechanics as floppy drives.
> That's the head stepper motor.
> Today one surface of one platter is given over the the address marks
> and track alignment data. Thus each track has its own index and index
> errors from the outer track are no longer cumulative. Track seeks
> are performed using a servo mechanism.  This allows much closer track
> spacing to be achieved than with a head stepper.
>
> As there is no longer any head stepper, its no longer possible to perform
> a traditional low level format and rewrite the address marks on a HDD.
> The address marks and track alignment data are read only.
> Readers with long memories may remember destroying early 'voice coil'
> actuated drives by carrying out a low level format, as was the habit
> at the time.
>
> >
> > If in the A/R example the data sets of sales, customer, inventory,
> > and prices are on a Windows partition E: but the A/R creates the
> > A/R print file on partition H: nearest the drive hub. The H: drive
> > index does not get the bad sectors and the head miss-aligning is less
> > at the index to the hub drive rather then at maximum at the rim drive.
> >
> > The source data files on drive E: are only read so they will suffer
> > no hot writes or bad sectors.
> >
> > It is my intention to test for similar consequences with Linux
> > partitioning to see if there may be benefits in heavy drive use
> > as may be in server systems.
> >
>
> I will be interested in both your test methods and results.
>
> >
> > Dee
> > adaudio at bc1.com
> >
> >
> >
> > _______________________________________________
> > EdLUG mailing list
> > EdLUG at lists.edlug.org.uk
> > https://lists.edlug.org.uk/mailman/listinfo/edlug
> >
>
>
> _______________________________________________
> EdLUG mailing list
> EdLUG at lists.edlug.org.uk
> https://lists.edlug.org.uk/mailman/listinfo/edlug
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.edlug.org.uk/pipermail/edlug/attachments/20160526/25f50d65/attachment.html>