[EdLUG] mounting name adjustment & personal

[Edinburgh Linux Users Group]

Hellow edlug.org

Attn:  Tai Kedzierski


I purchase British Linux magazines at my local newsstand.
This is part of my excuse to drive from Duncan to the
larger Victoria where they sell imported Linux magazines.

I get these about a month to a month to two late. It is a
social thing as I stretch the excuse to visit old Windows
friends to wean them to Linux.

The BC Canada LUGs are less than the active hives they were
only a few years ago. In Linux Format there are listings of
British LUGs and I made an ASCII contact list on my system
with home URLs and any other contact info.

I have just finished reading Jack Whyte's novel 'the Guardian'
about William Wallace and Andrew Murray in their first success
to drive Edward I and his English nobles out of Scotland.

As my Russian family claims a Scott in our gene pool it is
quite natural that I would pick the Edinburgh LUG to contact.
Also the Scott have engineering in the blood by reputation
so I was sure to get a valid hit.

You have given me much to follow up on with my mounting issues.
Thanks for that.

In my Q4 on partitioning for speed - I tan trials in Windows 95,
Windows 98SE, Win XP (32bit). A 1/3rd partition was not 3 times
faster but each part was much faster than the whole drive as C:.

Th most beneficial gain in partitioning Windows is that the hub
most partition would not fail with bad sectors. I did some studies
into bad sectors and found most being made due to 'hot writes'.

In an extensive defrag or any operation of software that multiplies
some existing files to create a new file as in an accounts
receivable generation at month's end. A transaction is opened to
start an A?R print file. The customer data set is read to add to
the print all the billing information, then the head(s) locate the
1st inventory item for description and price. Then the head(s) find
the next sale for that invoice or go to start the next invoice.

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.

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.

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.

If you know of any Linux IT folks pass this on. The Linux file
systems have features to protect data but understanding how
heated data writes can cause problems with some operating systems
may be helpful in reducing excess and slowing code to work around
related problems.

This is not what I share with the Windows community who generally
can not think past one giant garbage collector as a drive C:.

I look forward to more mails with you as my Linux skills develop.

Dee
adaudio at bc1.com