public inbox for speakup@linux-speakup.org
 help / color / mirror / Atom feed
From: Gregory Nowak <greg@romuald.net.eu.org>
To: speakup@braille.uwo.ca
Subject: Re: A computer issue, how should I deal with this? Best solution?
Date: Sun, 24 Jun 2007 15:40:27 -0700	[thread overview]
Message-ID: <20070624224026.GA24723@localhost.localdomain> (raw)
In-Reply-To: <007e01c7b67b$04e90080$b100a8c0@AveratecLaptop>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sun, Jun 24, 2007 at 11:16:27AM -0500, Glenn Ervin wrote:
> As far as NTFS being more reliable than FAT32, I would argue on personal 
> experience  that I have had more drives go bad that were running NTFS than 
> those running FAT32.

While I don't mean to, and can't dispute your personal experience, as far as I know, there is no connection what so ever between the file
system on a drive, and whether the drive goes bad or not, I don't
follow this line of reasoning. That's like someone saying they got a
flat tire, because they were driving in a rain storm.

> I have owned more drives formatted with FAT32, so I should have experienced 
> more FAT32 file system problems, yet I have experienced the opposite.

This looks logical on the surface, but really isn't if you think about
it. Sticking with the car analogy, that's like saying that if you
drive the same model/year of car for an equal amount of time, both cars
will use exactly the same amount of gas. On the surface, this looks
logical, but really isn't if you stop and consider it, (I won't
explain why here. Coming back to the hd and fs comparison, the only
way to test such a hypothesis, would be to have 2 drives of the same
make and model, produced in the same factory on the same date, one
formated with fat32, the other with ntfs. Even then, your results
still couldn't be said to be accurate, because the workmanship on each
drive might have varied, the materials, although the same, used to
construct the drives might have varied in some small way, and the
amount of use each drive got would most likely vary as well. 

Keep in mind that modern drives have more heads, and more cylinders than
older drives, while still being confined to the same physical size
limit. Therefore, there are more heads, and more media in a newer
drive that could fail, as opposed to the older drives. It is also
possible that due to newer drives being internally more complex then
older drives (see previous head/cylinder comparison), that quality
control today isn't as thorough as it once used to be. In addition to
more complexity, another reason for poorer quality control is that the
size of drives is increasing, and prices are coming down steadily. So,
companies making these drives either could be expecting people to
upgrade more often, thus they aren't concerned with the drive having
an especially long lifetime, or they could purposefully be making more
flaky drives, so as to force people to buy newer drives, thus keeping
their business going. I am only proposing a theory here, I'm not saying
that this is what manufactures are actually doing, though they might be.

> Now this can be due to mechanical problems un-relat
ed to the file system, 
> but it is often unclear whether the hard-drive crash was due to an inability 
> for the file system being able to repair itself.

You said it yourself, a hard drive is a mechanical, (well actually, an
electro-mechanical) device. If it
mechanically breaks, and crashes, no file system put on it, before, or
somehow after the crash, would bring that drive magically back to
life. As for the inability of a file system to repair itself causing
the drive to crash hardware wise, this is something else that doesn't
make sense, to me at least.

Greg


- -- 
web site: http://www.romuald.net.eu.org
gpg public key: http://www.romuald.net.eu.org/pubkey.asc
skype: gregn1
(authorization required, add me to your contacts list first)

- --
Free domains: http://www.eu.org/ or mail dns-manager@EU.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFGfvLa7s9z/XlyUyARAmKfAKCpOqomieK3EELD8VO3lStdPbF/4gCglSHn
bhqImSZ+e6gBNLWzkgYFn0A=
=FEjp
-----END PGP SIGNATURE-----


  reply	other threads:[~ UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
 Keith Hinton
 ` Willem van der Walt
 ` Doug Sutherland
   ` Gregory Nowak
   ` Glenn Ervin
     ` Gregory Nowak
       ` Gregory Nowak
         ` Butch Bussen
           ` Doug Sutherland
             ` Gaijin
             ` Butch Bussen
       ` Glenn Ervin
     ` Doug Sutherland
       ` Glenn Ervin
         ` Doug Sutherland
           ` Glenn Ervin
             ` Doug Sutherland
               ` Butch Bussen
                 ` Glenn Ervin
                 ` Doug Sutherland
                   ` Steve Holmes
                     ` Doug Sutherland
                       ` Glenn Ervin
                         ` Gregory Nowak [this message]
                           ` Glenn Ervin
                             ` Gregory Nowak
           ` Butch Bussen
       ` Butch Bussen
 ` John Heim
 ` Gaijin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20070624224026.GA24723@localhost.localdomain \
    --to=greg@romuald.net.eu.org \
    --cc=speakup@braille.uwo.ca \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).