L
Leythos
It's always amazing how the antiDefrag group's zealots will create what
appear to be technical reasons for not doing it, etc... Even unix
systems benefit from packing the drives.
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an alternative browser.
You should upgrade or use an alternative browser.
It's always amazing how the antiDefrag group's zealots will create what
appear to be technical reasons for not doing it, etc... Even unix
systems benefit from packing the drives.
L
Leythos
My hard drives are all NTFS, so I defrag every year or two.
My drives are all NTFS too, and they require defragmentation for proper
performance maintenance. If you don't really use your system then you
don't need to defragment it very often. If you make heavy use of add,
delete, insert, etc... then you benefit from defrag based on your
volume.
There is no one case works for everyone as many people have different
levels of file use.
P
PopS
....PaulFXH said:PopS escreveu:
Hi PopS
I'm interested in your comment that "It hurts nothing to
defrag".
I recently received the following advice in another group
(serious
thread, competent people) which strongly suggests that
frequent, and
particularly unnecessary, defragging should be avoided:
"If you don't have ECC memory frequent defragging can be very
harmful. Each file move passes through a memory buffer, and
there
is NO check for dropped or altered bits in that buffer. So you
can
be gradually destroying your files with no warning. "
Do you, or anybody else, believe that this factor really does
need to
be considered for those of us without ECC RAM?
HI,
I'm familiar with what you refer to. There are purists, and then
there are purists, and then there's everyone else <g>. Books
could be written debating this back and forth, and in fact, just
on debating whether it should be debated or not!
Here's my take on it, meaning my opinion:
Not a single thing they say about the possibiility of problems
happening is untrue. BUT ... they are mostly talking
theoretically and statistically, with the exception of some
fanatics that insist the whole world must agree with them, or it
will end<g>. I don't argue with that point: The more complexity
to -anything-, the more chance there is for error to creep in.
Then again, based on real world experience of myself and
everyone else I've ever come in contact with on a more than very
casual level, the real world says reliability is more than
sufficient in today's machines, and a defrag will not result in
any more damage likelihood than copying a file from one folder to
another. And that is basically what defrag does. Only instead
of moving between folders, it simply copies files over to
different physical locations on the hard drive. Either way, it's
the same operation: Read a byte from here, write the byte over
there.
So no, I don't worry about that end of things. I defrag
often.
Now, if I knew my hard drive was having problems or SMART went
off and warned that something wasn't healthy with the drive, then
I would not defrag it. But, neither would I copy any more files
to or from it, and I'd avoid using it as much as possible until I
got that problem taken care of. So again, defrag doesn't get
singled out.
To date I have never met anyone face to face or seen a system
that was damaged by a defrag. Nor copying a file, for that
matter, and it's the same sort of process. The first "defrag"
program I ever saw was back in the days of CP/M, an old, OLD
operating system predating even Bill Gates, and I've used defrag
(of one type or another) software ever since.
This machine I am on now is continuously being defragged in the
background. Whenever it's idle, the defrag cuts in and looks to
see if any drives can be defragged; if so, it goes ahead and
starts doing it. If I touch any keys, it stops and goes back to
sleep, in order to stay out of my way, and doesn't restart again
until the machine has been idle for 5 minutes. So, in a manner
of speaking it'd a continuous defrag that never stops.
I don't have that particular software on my laptop, so that one I
defrag whenever I've copied or moved or edited more than a few
files or installed/uninstalled any software on it.
Aside:
BTW, in the "old days" the most convenient method of defragging
those huge behoths of ten MEGabyte drives, more space than we
could ever possibly even dream of using, the method for defrag
was to:
-- Copy all the data someplace else.
-- Erase all the data after it's been copied.
-- Then copy it all back. When you were done, you had defragged
that monstrous 10 MB hard drive!
My first floppy disk measured 9 inches in diameter and held a
whopping 45kB worth of data. IN other words, everything is
relative! <G>
Defrag all you want, IMO. Most everyone else will agree with
that.
Cheers,
Pop
D
David Candy
The point is it is not necessary. It is of marginal utility in XP (as XP does mini defrags anyway). But most of all it is about defragger companies stealing money by fraud using FUD.
I know someone like you has no clue and has no intellectual discipline. So assume I install XP, run defrag manually once, wait a year - what is the impact of not defragging for that year.
I've already made posts about this. Your turn.
I know someone like you has no clue and has no intellectual discipline. So assume I install XP, run defrag manually once, wait a year - what is the impact of not defragging for that year.
I've already made posts about this. Your turn.
P
PaulFXH
PopS escreveu:
Hi Pop
Thanks for your most informative reply and advice.
However, I notice that you don't mention the need (or lack of a need)
for ECC RAM to minimize file damage due to frequent defragging.
The poster who alerted me to this potential problem insisted on ECC RAM
being essential for this purpose.
Any thoughts?
TIA
Paul
...
HI,
I'm familiar with what you refer to. There are purists, and then
there are purists, and then there's everyone else <g>. Books
could be written debating this back and forth, and in fact, just
on debating whether it should be debated or not!
Here's my take on it, meaning my opinion:
Not a single thing they say about the possibiility of problems
happening is untrue. BUT ... they are mostly talking
theoretically and statistically, with the exception of some
fanatics that insist the whole world must agree with them, or it
will end<g>. I don't argue with that point: The more complexity
to -anything-, the more chance there is for error to creep in.
Then again, based on real world experience of myself and
everyone else I've ever come in contact with on a more than very
casual level, the real world says reliability is more than
sufficient in today's machines, and a defrag will not result in
any more damage likelihood than copying a file from one folder to
another. And that is basically what defrag does. Only instead
of moving between folders, it simply copies files over to
different physical locations on the hard drive. Either way, it's
the same operation: Read a byte from here, write the byte over
there.
So no, I don't worry about that end of things. I defrag
often.
Now, if I knew my hard drive was having problems or SMART went
off and warned that something wasn't healthy with the drive, then
I would not defrag it. But, neither would I copy any more files
to or from it, and I'd avoid using it as much as possible until I
got that problem taken care of. So again, defrag doesn't get
singled out.
To date I have never met anyone face to face or seen a system
that was damaged by a defrag. Nor copying a file, for that
matter, and it's the same sort of process. The first "defrag"
program I ever saw was back in the days of CP/M, an old, OLD
operating system predating even Bill Gates, and I've used defrag
(of one type or another) software ever since.
This machine I am on now is continuously being defragged in the
background. Whenever it's idle, the defrag cuts in and looks to
see if any drives can be defragged; if so, it goes ahead and
starts doing it. If I touch any keys, it stops and goes back to
sleep, in order to stay out of my way, and doesn't restart again
until the machine has been idle for 5 minutes. So, in a manner
of speaking it'd a continuous defrag that never stops.
I don't have that particular software on my laptop, so that one I
defrag whenever I've copied or moved or edited more than a few
files or installed/uninstalled any software on it.
Aside:
BTW, in the "old days" the most convenient method of defragging
those huge behoths of ten MEGabyte drives, more space than we
could ever possibly even dream of using, the method for defrag
was to:
-- Copy all the data someplace else.
-- Erase all the data after it's been copied.
-- Then copy it all back. When you were done, you had defragged
that monstrous 10 MB hard drive!
My first floppy disk measured 9 inches in diameter and held a
whopping 45kB worth of data. IN other words, everything is
relative! <G>
Defrag all you want, IMO. Most everyone else will agree with
that.
Hi Pop
Thanks for your most informative reply and advice.
However, I notice that you don't mention the need (or lack of a need)
for ECC RAM to minimize file damage due to frequent defragging.
The poster who alerted me to this potential problem insisted on ECC RAM
being essential for this purpose.
Any thoughts?
TIA
Paul
P
PopS
....
Sorry; thought that was settled. Guess I got off track. I've
had three machines that used ECC RAM and had no problems, plus
have never seen anything realiably that back up it bieng a
problem. I looked back to see what you said, and w/r to that, if
it were a problem, then there would also be problems with the
thousands of temporary files that are created/deleted as you use
your machine, problems copying files from one place to another,
moving files, etc. etc..
Just for grins since I haven't done much RAM research lately, I
did a little digging at Google and after about fifteen minutes
hadn't found anything that might or would lead to any issues such
as you mention. Defrag just won't come into the picture as an
issue. If it does, it won't be alone; there will be other things
wrong, they'll be noticeable before one ever does a defrag, and
it won't be the cause of any problems.
Them's my thoughts, anyway
Pop
Hi Pop
Thanks for your most informative reply and advice.
However, I notice that you don't mention the need (or lack of a
need)
for ECC RAM to minimize file damage due to frequent defragging.
The poster who alerted me to this potential problem insisted on
ECC RAM
being essential for this purpose.
Any thoughts?
TIA
Paul
Sorry; thought that was settled. Guess I got off track. I've
had three machines that used ECC RAM and had no problems, plus
have never seen anything realiably that back up it bieng a
problem. I looked back to see what you said, and w/r to that, if
it were a problem, then there would also be problems with the
thousands of temporary files that are created/deleted as you use
your machine, problems copying files from one place to another,
moving files, etc. etc..
Just for grins since I haven't done much RAM research lately, I
did a little digging at Google and after about fifteen minutes
hadn't found anything that might or would lead to any issues such
as you mention. Defrag just won't come into the picture as an
issue. If it does, it won't be alone; there will be other things
wrong, they'll be noticeable before one ever does a defrag, and
it won't be the cause of any problems.
Them's my thoughts, anyway
Pop
P
PaulFXH
PopS escreveu:
Hi Pop,
Thanks for your reply and I apologize for my persistence in this matter
but you are providing a very interesting assessment of this concern
that I have had since receiving the post I mentioned earlier in this
thread.
However, I don't seem to be explaining myself well wrt to what type of
RAM is thought to be more liable to cause problems because of frequent
defragmentation.
The guy who alerted me to this was insistent that ECC (Error Checking
and Correcting) RAM was essential to AVOID defrag-induced file
corruption -- NOT the other way around as you seem to have understood
it.
Thus when you say that you've "had three machines that used ECC RAM and
had no problems", that's exactly what this guy would expect.
However, have you any experience in frequent defragging of machines
with non-ECC RAM?
According to my correspondent, it is ONLY in these cases that
defragging will lead to file corruption.
Apologies once again but I seem to be on the verge of finally
understanding (or dismissing) this concern.
TIA
Paul
...
Sorry; thought that was settled. Guess I got off track. I've
had three machines that used ECC RAM and had no problems, plus
have never seen anything realiably that back up it bieng a
problem.
Hi Pop,
Thanks for your reply and I apologize for my persistence in this matter
but you are providing a very interesting assessment of this concern
that I have had since receiving the post I mentioned earlier in this
thread.
However, I don't seem to be explaining myself well wrt to what type of
RAM is thought to be more liable to cause problems because of frequent
defragmentation.
The guy who alerted me to this was insistent that ECC (Error Checking
and Correcting) RAM was essential to AVOID defrag-induced file
corruption -- NOT the other way around as you seem to have understood
it.
Thus when you say that you've "had three machines that used ECC RAM and
had no problems", that's exactly what this guy would expect.
However, have you any experience in frequent defragging of machines
with non-ECC RAM?
According to my correspondent, it is ONLY in these cases that
defragging will lead to file corruption.
Apologies once again but I seem to be on the verge of finally
understanding (or dismissing) this concern.
TIA
Paul
P
PopS
Interesting how mixed up things can get sometimes, isn't it? No
apology necessary; my problem, not yours.
First, here's a link that gives sort of an overall description
of ECC cs non-ECC:
http://arstechnica.com/paedia/r/ram_id-2.html
Here's a page that I think is a good clear description of RAM
chips & modules:
http://www.researchut.com/docs/meminfo.html
....
Neither, in my experience. I seriously doubt that the home user
is going to ever see a difference between the two. I'm
wondering now, from your latest syntax, if your source wasn't
referring ro RAM fragmentation w/r to DVD RAMs, DVD ROM, etc.,
and not DRIVE fragmentation.
Another thing to keep in mind is sometimes you simply cannot
physically install ECC and non-ECC RAM in the same slots without
an adapter board of some kind. They have differing numbers of
pins on them. But then on the other hand, as you'll see in the
second URL I posted above, ...
And, most importantly, ALWAYS use only ONE type and speed RAM
sticks in any given machine. Mixing them is always very chancey
and can result in problems. But, that's not what you were
asking; just thought it important to point out.
So for instance, since I'm already using DDR 256 MB PC3200
memory sticks, if I add more memory, they have to be the same
type and speed as what's already there, or, I have to replace
what's there also with the new type, making sure its fast enough
for my 3 GHz machine.
I probably did get it mixed up; sorry.
Yes. The majority of my machines have NOT required ECC RAM.
Since I wanted to be able to say I'd used machines requiring ECC
RAM for sure, I jumped back into my archives and looked up the
RAM chips and modules over the years.
And this is where I'll respectfully disagree. I just don't think
it's an issue these days. Or, more directly, it's just not an
issue unless you're talking about high end workstations or
another implementation such as DVD drives etc..
No apologies necessary, in any way. I hope the links above will
help, or at least give you enough description to allow you to
further research the issue.
Regards,
Pop
apology necessary; my problem, not yours.
First, here's a link that gives sort of an overall description
of ECC cs non-ECC:
http://arstechnica.com/paedia/r/ram_id-2.html
Here's a page that I think is a good clear description of RAM
chips & modules:
http://www.researchut.com/docs/meminfo.html
....
Hi Pop,
Thanks for your reply and I apologize for my persistence in
this matter
but you are providing a very interesting assessment of this
concern
that I have had since receiving the post I mentioned earlier in
this
thread.
However, I don't seem to be explaining myself well wrt to what
type of
RAM is thought to be more liable to cause problems because of
frequent
defragmentation.
Neither, in my experience. I seriously doubt that the home user
is going to ever see a difference between the two. I'm
wondering now, from your latest syntax, if your source wasn't
referring ro RAM fragmentation w/r to DVD RAMs, DVD ROM, etc.,
and not DRIVE fragmentation.
Another thing to keep in mind is sometimes you simply cannot
physically install ECC and non-ECC RAM in the same slots without
an adapter board of some kind. They have differing numbers of
pins on them. But then on the other hand, as you'll see in the
second URL I posted above, ...
And, most importantly, ALWAYS use only ONE type and speed RAM
sticks in any given machine. Mixing them is always very chancey
and can result in problems. But, that's not what you were
asking; just thought it important to point out.
So for instance, since I'm already using DDR 256 MB PC3200
memory sticks, if I add more memory, they have to be the same
type and speed as what's already there, or, I have to replace
what's there also with the new type, making sure its fast enough
for my 3 GHz machine.
The guy who alerted me to this was insistent that ECC (Error
Checking
and Correcting) RAM was essential to AVOID defrag-induced file
corruption -- NOT the other way around as you seem to have
understood
it.
I probably did get it mixed up; sorry.
Thus when you say that you've "had three machines that used ECC
RAM and
had no problems", that's exactly what this guy would expect.
However, have you any experience in frequent defragging of
machines
with non-ECC RAM?
Yes. The majority of my machines have NOT required ECC RAM.
Since I wanted to be able to say I'd used machines requiring ECC
RAM for sure, I jumped back into my archives and looked up the
RAM chips and modules over the years.
According to my correspondent, it is ONLY in these cases that
defragging will lead to file corruption.
And this is where I'll respectfully disagree. I just don't think
it's an issue these days. Or, more directly, it's just not an
issue unless you're talking about high end workstations or
another implementation such as DVD drives etc..
....Apologies once again but I seem to be on the verge of finally
understanding (or dismissing) this concern.
TIA
Paul
No apologies necessary, in any way. I hope the links above will
help, or at least give you enough description to allow you to
further research the issue.
Regards,
Pop
G
Greg Hayes/Raxco Software
Phil,
All defragmenters (from built-in to low cost to to commercial) use
Microsoft's defrag APIs (part of Windows) - which ensures that
defragmenting is performed in a Microsoft safe and supported manner.
In my years of dealing with the file system from a fragmentation
perspective, there is only 1 case where use of Microsoft's defrag APIs
resulted in corruption. Windows 2000 RC2. FAT drive greater than 4GB.
There was a math error. Other than that - none. There is a bug with
Windows 2000 where the file system calls out a false positive for possible
corruption when a defrag is performed. False positive because there
actually isn't any problem.
- Greg/Raxco Software
Microsoft MVP - Windows File System
Disclaimer: I work for Raxco Software, the maker of PerfectDisk - a
commercial defrag utility, as a systems engineer in the support department.
Want to email me? Delete ntloader.
All defragmenters (from built-in to low cost to to commercial) use
Microsoft's defrag APIs (part of Windows) - which ensures that
defragmenting is performed in a Microsoft safe and supported manner.
In my years of dealing with the file system from a fragmentation
perspective, there is only 1 case where use of Microsoft's defrag APIs
resulted in corruption. Windows 2000 RC2. FAT drive greater than 4GB.
There was a math error. Other than that - none. There is a bug with
Windows 2000 where the file system calls out a false positive for possible
corruption when a defrag is performed. False positive because there
actually isn't any problem.
- Greg/Raxco Software
Microsoft MVP - Windows File System
Disclaimer: I work for Raxco Software, the maker of PerfectDisk - a
commercial defrag utility, as a systems engineer in the support department.
Want to email me? Delete ntloader.
P
Phil Weldon
| Hi Phil
| Does this mean that ALL defraggers do include some type of
| error-checking and not just those incorporated on machines with ECC
| RAM?
| In this case my advisors remarks regarding the necessity to ensure the
| computer has ECC RAM are invalid (when frequent defragging is intended
| or necessary)?
_____
Yes, all of the replies posted to your original question are essentially
the same.
And yes, all defragmentation utilities that you would use include
error-checking.
ECC RAM does not contribute significantly to error free defragging.
Defragging consists of
WHILE fragmentation exists
reading clusters of data into memory
THEN
rewriting the same data to another part of the hard drive
THEN
comparing the original data to the new copy
THEN
IF
the copy = original
THEN
deallocating the original clusters
ECC RAM can detect and correct a 1 bit error in every 32 bits; it can
detect, but not correct, a 2 bit error in every 32 bits.
The error rate for hard drives is much higher than the error rates for any
type of RAM that is proper for the system.
Therefore ECC RAM adds insignificantly to the safety of defragmenting a
hard drive.
(The above explanation is simplified, and does not get into maintaining
directories, etc.)
Now, if you could just explain why half my spam is from Brazil, and in
Portuguese! B^)
Phil Weldon
|
| Phil Weldon escreveu:
|
| > 'Leythos' wrote:
| > | I've been using computers since the 70's, and as soon as defragging
| > | became available it was used, on most platforms. I have servers that
run
| > | 24/7/365 that defrag every night on schedule, ones that defrag for
| > | several hours doing as many defrags during that period as possible,
| > | etc... I've never experienced data loss during/because of a defrag,
even
| > | during a unplanned restart of the system during a defrag.
| > _____
| >
| > Because the defragger reads a cluster, rewrites in a new location, then
| > checks the original against the copy before releasing the original
cluster
| > to be used.
|
| Hi Phil
| Does this mean that ALL defraggers do include some type of
| error-checking and not just those incorporated on machines with ECC
| RAM?
| In this case my advisors remarks regarding the necessity to ensure the
| computer has ECC RAM are invalid (when frequent defragging is intended
| or necessary)?
|
| TIA
| Paul
|
| >
| > Phil Weldon
| >
| > | > | In article <[email protected]>,
| > | (e-mail address removed) says...
| > | > "If you don't have ECC memory frequent defragging can be very
| > | > harmful. Each file move passes through a memory buffer, and there
| > | > is NO check for dropped or altered bits in that buffer. So you can
| > | > be gradually destroying your files with no warning. "
| > | >
| > | > Do you, or anybody else, believe that this factor really does need
to
| > | > be considered for those of us without ECC RAM?
| > |
| > | I've been using computers since the 70's, and as soon as defragging
| > | became available it was used, on most platforms. I have servers that
run
| > | 24/7/365 that defrag every night on schedule, ones that defrag for
| > | several hours doing as many defrags during that period as possible,
| > | etc... I've never experienced data loss during/because of a defrag,
even
| > | during a unplanned restart of the system during a defrag.
| > |
| > |
| > |
| > | --
| > |
| > | (e-mail address removed)
| > | remove 999 in order to email me
|
| Does this mean that ALL defraggers do include some type of
| error-checking and not just those incorporated on machines with ECC
| RAM?
| In this case my advisors remarks regarding the necessity to ensure the
| computer has ECC RAM are invalid (when frequent defragging is intended
| or necessary)?
_____
Yes, all of the replies posted to your original question are essentially
the same.
And yes, all defragmentation utilities that you would use include
error-checking.
ECC RAM does not contribute significantly to error free defragging.
Defragging consists of
WHILE fragmentation exists
reading clusters of data into memory
THEN
rewriting the same data to another part of the hard drive
THEN
comparing the original data to the new copy
THEN
IF
the copy = original
THEN
deallocating the original clusters
ECC RAM can detect and correct a 1 bit error in every 32 bits; it can
detect, but not correct, a 2 bit error in every 32 bits.
The error rate for hard drives is much higher than the error rates for any
type of RAM that is proper for the system.
Therefore ECC RAM adds insignificantly to the safety of defragmenting a
hard drive.
(The above explanation is simplified, and does not get into maintaining
directories, etc.)
Now, if you could just explain why half my spam is from Brazil, and in
Portuguese! B^)
Phil Weldon
|
| Phil Weldon escreveu:
|
| > 'Leythos' wrote:
| > | I've been using computers since the 70's, and as soon as defragging
| > | became available it was used, on most platforms. I have servers that
run
| > | 24/7/365 that defrag every night on schedule, ones that defrag for
| > | several hours doing as many defrags during that period as possible,
| > | etc... I've never experienced data loss during/because of a defrag,
even
| > | during a unplanned restart of the system during a defrag.
| > _____
| >
| > Because the defragger reads a cluster, rewrites in a new location, then
| > checks the original against the copy before releasing the original
cluster
| > to be used.
|
| Hi Phil
| Does this mean that ALL defraggers do include some type of
| error-checking and not just those incorporated on machines with ECC
| RAM?
| In this case my advisors remarks regarding the necessity to ensure the
| computer has ECC RAM are invalid (when frequent defragging is intended
| or necessary)?
|
| TIA
| Paul
|
| >
| > Phil Weldon
| >
| > | > | In article <[email protected]>,
| > | (e-mail address removed) says...
| > | > "If you don't have ECC memory frequent defragging can be very
| > | > harmful. Each file move passes through a memory buffer, and there
| > | > is NO check for dropped or altered bits in that buffer. So you can
| > | > be gradually destroying your files with no warning. "
| > | >
| > | > Do you, or anybody else, believe that this factor really does need
to
| > | > be considered for those of us without ECC RAM?
| > |
| > | I've been using computers since the 70's, and as soon as defragging
| > | became available it was used, on most platforms. I have servers that
run
| > | 24/7/365 that defrag every night on schedule, ones that defrag for
| > | several hours doing as many defrags during that period as possible,
| > | etc... I've never experienced data loss during/because of a defrag,
even
| > | during a unplanned restart of the system during a defrag.
| > |
| > |
| > |
| > | --
| > |
| > | (e-mail address removed)
| > | remove 999 in order to email me
|
P
PaulFXH
PopS escreveu:
Pop,
Thanks for your reply and the links.
However, I think this concern has run out of steam and I doubt if I'll
be researching any further.
Best wishes
Paul
Interesting how mixed up things can get sometimes, isn't it? No
apology necessary; my problem, not yours.
First, here's a link that gives sort of an overall description
of ECC cs non-ECC:
http://arstechnica.com/paedia/r/ram_id-2.html
Here's a page that I think is a good clear description of RAM
chips & modules:
http://www.researchut.com/docs/meminfo.html
...
Neither, in my experience. I seriously doubt that the home user
is going to ever see a difference between the two. I'm
wondering now, from your latest syntax, if your source wasn't
referring ro RAM fragmentation w/r to DVD RAMs, DVD ROM, etc.,
and not DRIVE fragmentation.
Another thing to keep in mind is sometimes you simply cannot
physically install ECC and non-ECC RAM in the same slots without
an adapter board of some kind. They have differing numbers of
pins on them. But then on the other hand, as you'll see in the
second URL I posted above, ...
And, most importantly, ALWAYS use only ONE type and speed RAM
sticks in any given machine. Mixing them is always very chancey
and can result in problems. But, that's not what you were
asking; just thought it important to point out.
So for instance, since I'm already using DDR 256 MB PC3200
memory sticks, if I add more memory, they have to be the same
type and speed as what's already there, or, I have to replace
what's there also with the new type, making sure its fast enough
for my 3 GHz machine.
I probably did get it mixed up; sorry.
Yes. The majority of my machines have NOT required ECC RAM.
Since I wanted to be able to say I'd used machines requiring ECC
RAM for sure, I jumped back into my archives and looked up the
RAM chips and modules over the years.
And this is where I'll respectfully disagree. I just don't think
it's an issue these days. Or, more directly, it's just not an
issue unless you're talking about high end workstations or
another implementation such as DVD drives etc..
...
No apologies necessary, in any way. I hope the links above will
help, or at least give you enough description to allow you to
further research the issue.
Pop,
Thanks for your reply and the links.
However, I think this concern has run out of steam and I doubt if I'll
be researching any further.
Best wishes
Paul
P
PaulFXH
Phil Weldon escreveu:
Hi Phil,
Thanks for your reply and explanation.
Looks like this concern of mine has been unanimously ruled unnecessary
so I'm going to have to find something else to be worried about.
Unfortunately, on this issue I can do little more than confirm that
it's not coming from me.
Nevertheless, on the positive side, it might well offer you an
opportunity to brush up on what is the eighth most widely spoken
language in the world as well as being a richer and infinitely better
structured language than English.
Best wishes
Paul
| Hi Phil
| Does this mean that ALL defraggers do include some type of
| error-checking and not just those incorporated on machines with ECC
| RAM?
| In this case my advisors remarks regarding the necessity to ensure the
| computer has ECC RAM are invalid (when frequent defragging is intended
| or necessary)?
_____
Yes, all of the replies posted to your original question are essentially
the same.
And yes, all defragmentation utilities that you would use include
error-checking.
ECC RAM does not contribute significantly to error free defragging.
Defragging consists of
WHILE fragmentation exists
reading clusters of data into memory
THEN
rewriting the same data to another part of the hard drive
THEN
comparing the original data to the new copy
THEN
IF
the copy = original
THEN
deallocating the original clusters
ECC RAM can detect and correct a 1 bit error in every 32 bits; it can
detect, but not correct, a 2 bit error in every 32 bits.
The error rate for hard drives is much higher than the error rates for any
type of RAM that is proper for the system.
Therefore ECC RAM adds insignificantly to the safety of defragmenting a
hard drive.
Hi Phil,
Thanks for your reply and explanation.
Looks like this concern of mine has been unanimously ruled unnecessary
so I'm going to have to find something else to be worried about.
(The above explanation is simplified, and does not get into maintaining
directories, etc.)
Now, if you could just explain why half my spam is from Brazil, and in
Portuguese! B^)
Unfortunately, on this issue I can do little more than confirm that
it's not coming from me.
Nevertheless, on the positive side, it might well offer you an
opportunity to brush up on what is the eighth most widely spoken
language in the world as well as being a richer and infinitely better
structured language than English.
Best wishes
Paul
P
Phil Weldon
'PaulFXH' wrote:
| Thanks for your reply and explanation.
| Looks like this concern of mine has been unanimously ruled unnecessary
| so I'm going to have to find something else to be worried about.
|
| >
| > (The above explanation is simplified, and does not get into maintaining
| > directories, etc.)
| >
| > Now, if you could just explain why half my spam is from Brazil, and in
| > Portuguese! B^)
|
| Unfortunately, on this issue I can do little more than confirm that
| it's not coming from me.
| Nevertheless, on the positive side, it might well offer you an
| opportunity to brush up on what is the eighth most widely spoken
| language in the world as well as being a richer and infinitely better
| structured language than English.
_____
Let's see,
Chinese
Spanish?
English?
Hindi?
Arabic?
French?
Russian?
Portuguese.
I just can't figure out why I get so much spam from Brazil - I've worked in
Bolivia and Columbia, but never Brazil. I guess when sending spam is free,
it does not matter if the recipient can read the message.
And English is a very rich language - and it should be - English has adopted
words from more languages than perhaps any other. Unfortunately it as also
adopted a few rules from this one, that one, and the other. Logical it
isn't. I did study Latin - now that was a logical language, but WAY too
many noun and verb forms.
I will take your suggestion and actually try to read some of the Portuguese
language spam; though I guess that spam is not really the place to see good
use of language B^)
|
| Phil Weldon escreveu:
|
| > | Hi Phil
| > | Does this mean that ALL defraggers do include some type of
| > | error-checking and not just those incorporated on machines with ECC
| > | RAM?
| > | In this case my advisors remarks regarding the necessity to ensure the
| > | computer has ECC RAM are invalid (when frequent defragging is intended
| > | or necessary)?
| > _____
| >
| > Yes, all of the replies posted to your original question are
essentially
| > the same.
| > And yes, all defragmentation utilities that you would use include
| > error-checking.
| >
| > ECC RAM does not contribute significantly to error free defragging.
| >
| > Defragging consists of
| > WHILE fragmentation exists
| > reading clusters of data into memory
| > THEN
| > rewriting the same data to another part of the hard
drive
| > THEN
| > comparing the original data to the new copy
| > THEN
| > IF
| > the copy = original
| > THEN
| > deallocating the original clusters
| >
| > ECC RAM can detect and correct a 1 bit error in every 32 bits; it can
| > detect, but not correct, a 2 bit error in every 32 bits.
| >
| > The error rate for hard drives is much higher than the error rates for
any
| > type of RAM that is proper for the system.
| >
| > Therefore ECC RAM adds insignificantly to the safety of defragmenting a
| > hard drive.
|
| Hi Phil,
| Thanks for your reply and explanation.
| Looks like this concern of mine has been unanimously ruled unnecessary
| so I'm going to have to find something else to be worried about.
|
| >
| > (The above explanation is simplified, and does not get into maintaining
| > directories, etc.)
| >
| > Now, if you could just explain why half my spam is from Brazil, and in
| > Portuguese! B^)
|
| Unfortunately, on this issue I can do little more than confirm that
| it's not coming from me.
| Nevertheless, on the positive side, it might well offer you an
| opportunity to brush up on what is the eighth most widely spoken
| language in the world as well as being a richer and infinitely better
| structured language than English.
|
| Best wishes
| Paul
|
| >
| > Phil Weldon
| >
| >
| >
| > | > |
| > | Phil Weldon escreveu:
| > |
| > | > 'Leythos' wrote:
| > | > | I've been using computers since the 70's, and as soon as
defragging
| > | > | became available it was used, on most platforms. I have servers
that
| > run
| > | > | 24/7/365 that defrag every night on schedule, ones that defrag for
| > | > | several hours doing as many defrags during that period as
possible,
| > | > | etc... I've never experienced data loss during/because of a
defrag,
| > even
| > | > | during a unplanned restart of the system during a defrag.
| > | > _____
| > | >
| > | > Because the defragger reads a cluster, rewrites in a new location,
then
| > | > checks the original against the copy before releasing the original
| > cluster
| > | > to be used.
| > |
| > | Hi Phil
| > | Does this mean that ALL defraggers do include some type of
| > | error-checking and not just those incorporated on machines with ECC
| > | RAM?
| > | In this case my advisors remarks regarding the necessity to ensure the
| > | computer has ECC RAM are invalid (when frequent defragging is intended
| > | or necessary)?
| > |
| > | TIA
| > | Paul
| > |
| > | >
| > | > Phil Weldon
| > | >
| > | > | > | > | In article
| > | > | (e-mail address removed) says...
| > | > | > "If you don't have ECC memory frequent defragging can be very
| > | > | > harmful. Each file move passes through a memory buffer, and
there
| > | > | > is NO check for dropped or altered bits in that buffer. So you
can
| > | > | > be gradually destroying your files with no warning. "
| > | > | >
| > | > | > Do you, or anybody else, believe that this factor really does
need
| > to
| > | > | > be considered for those of us without ECC RAM?
| > | > |
| > | > | I've been using computers since the 70's, and as soon as
defragging
| > | > | became available it was used, on most platforms. I have servers
that
| > run
| > | > | 24/7/365 that defrag every night on schedule, ones that defrag for
| > | > | several hours doing as many defrags during that period as
possible,
| > | > | etc... I've never experienced data loss during/because of a
defrag,
| > even
| > | > | during a unplanned restart of the system during a defrag.
| > | > |
| > | > |
| > | > |
| > | > | --
| > | > |
| > | > | (e-mail address removed)
| > | > | remove 999 in order to email me
| > |
|
| Thanks for your reply and explanation.
| Looks like this concern of mine has been unanimously ruled unnecessary
| so I'm going to have to find something else to be worried about.
|
| >
| > (The above explanation is simplified, and does not get into maintaining
| > directories, etc.)
| >
| > Now, if you could just explain why half my spam is from Brazil, and in
| > Portuguese! B^)
|
| Unfortunately, on this issue I can do little more than confirm that
| it's not coming from me.
| Nevertheless, on the positive side, it might well offer you an
| opportunity to brush up on what is the eighth most widely spoken
| language in the world as well as being a richer and infinitely better
| structured language than English.
_____
Let's see,
Chinese
Spanish?
English?
Hindi?
Arabic?
French?
Russian?
Portuguese.
I just can't figure out why I get so much spam from Brazil - I've worked in
Bolivia and Columbia, but never Brazil. I guess when sending spam is free,
it does not matter if the recipient can read the message.
And English is a very rich language - and it should be - English has adopted
words from more languages than perhaps any other. Unfortunately it as also
adopted a few rules from this one, that one, and the other. Logical it
isn't. I did study Latin - now that was a logical language, but WAY too
many noun and verb forms.
I will take your suggestion and actually try to read some of the Portuguese
language spam; though I guess that spam is not really the place to see good
use of language B^)
|
| Phil Weldon escreveu:
|
| > | Hi Phil
| > | Does this mean that ALL defraggers do include some type of
| > | error-checking and not just those incorporated on machines with ECC
| > | RAM?
| > | In this case my advisors remarks regarding the necessity to ensure the
| > | computer has ECC RAM are invalid (when frequent defragging is intended
| > | or necessary)?
| > _____
| >
| > Yes, all of the replies posted to your original question are
essentially
| > the same.
| > And yes, all defragmentation utilities that you would use include
| > error-checking.
| >
| > ECC RAM does not contribute significantly to error free defragging.
| >
| > Defragging consists of
| > WHILE fragmentation exists
| > reading clusters of data into memory
| > THEN
| > rewriting the same data to another part of the hard
drive
| > THEN
| > comparing the original data to the new copy
| > THEN
| > IF
| > the copy = original
| > THEN
| > deallocating the original clusters
| >
| > ECC RAM can detect and correct a 1 bit error in every 32 bits; it can
| > detect, but not correct, a 2 bit error in every 32 bits.
| >
| > The error rate for hard drives is much higher than the error rates for
any
| > type of RAM that is proper for the system.
| >
| > Therefore ECC RAM adds insignificantly to the safety of defragmenting a
| > hard drive.
|
| Hi Phil,
| Thanks for your reply and explanation.
| Looks like this concern of mine has been unanimously ruled unnecessary
| so I'm going to have to find something else to be worried about.
|
| >
| > (The above explanation is simplified, and does not get into maintaining
| > directories, etc.)
| >
| > Now, if you could just explain why half my spam is from Brazil, and in
| > Portuguese! B^)
|
| Unfortunately, on this issue I can do little more than confirm that
| it's not coming from me.
| Nevertheless, on the positive side, it might well offer you an
| opportunity to brush up on what is the eighth most widely spoken
| language in the world as well as being a richer and infinitely better
| structured language than English.
|
| Best wishes
| Paul
|
| >
| > Phil Weldon
| >
| >
| >
| > | > |
| > | Phil Weldon escreveu:
| > |
| > | > 'Leythos' wrote:
| > | > | I've been using computers since the 70's, and as soon as
defragging
| > | > | became available it was used, on most platforms. I have servers
that
| > run
| > | > | 24/7/365 that defrag every night on schedule, ones that defrag for
| > | > | several hours doing as many defrags during that period as
possible,
| > | > | etc... I've never experienced data loss during/because of a
defrag,
| > even
| > | > | during a unplanned restart of the system during a defrag.
| > | > _____
| > | >
| > | > Because the defragger reads a cluster, rewrites in a new location,
then
| > | > checks the original against the copy before releasing the original
| > cluster
| > | > to be used.
| > |
| > | Hi Phil
| > | Does this mean that ALL defraggers do include some type of
| > | error-checking and not just those incorporated on machines with ECC
| > | RAM?
| > | In this case my advisors remarks regarding the necessity to ensure the
| > | computer has ECC RAM are invalid (when frequent defragging is intended
| > | or necessary)?
| > |
| > | TIA
| > | Paul
| > |
| > | >
| > | > Phil Weldon
| > | >
| > | > | > | > | In article
| > | > | (e-mail address removed) says...
| > | > | > "If you don't have ECC memory frequent defragging can be very
| > | > | > harmful. Each file move passes through a memory buffer, and
there
| > | > | > is NO check for dropped or altered bits in that buffer. So you
can
| > | > | > be gradually destroying your files with no warning. "
| > | > | >
| > | > | > Do you, or anybody else, believe that this factor really does
need
| > to
| > | > | > be considered for those of us without ECC RAM?
| > | > |
| > | > | I've been using computers since the 70's, and as soon as
defragging
| > | > | became available it was used, on most platforms. I have servers
that
| > run
| > | > | 24/7/365 that defrag every night on schedule, ones that defrag for
| > | > | several hours doing as many defrags during that period as
possible,
| > | > | etc... I've never experienced data loss during/because of a
defrag,
| > even
| > | > | during a unplanned restart of the system during a defrag.
| > | > |
| > | > |
| > | > |
| > | > | --
| > | > |
| > | > | (e-mail address removed)
| > | > | remove 999 in order to email me
| > |
|
P
PaulFXH
Phil Weldon escreveu:
Hi Phil
Actually, English is apparently second.
Check out this link: http://www.infoplease.com/ipa/A0775272.html
Interestingly, I am in Brazil yet rarely receive spam from this
country. Rather the majority tend to come from Africa with offers of
exhorbitant sums of money.
I am not at all disputing the fact that English is a rich language;
it's just that in my humble and highly ignorable opinion, Portuguese is
richer.
Aproveite e boa sorte
Paul
'PaulFXH' wrote:
| Thanks for your reply and explanation.
| Looks like this concern of mine has been unanimously ruled unnecessary
| so I'm going to have to find something else to be worried about.
|
| >
| > (The above explanation is simplified, and does not get into maintaining
| > directories, etc.)
| >
| > Now, if you could just explain why half my spam is from Brazil, and in
| > Portuguese! B^)
|
| Unfortunately, on this issue I can do little more than confirm that
| it's not coming from me.
| Nevertheless, on the positive side, it might well offer you an
| opportunity to brush up on what is the eighth most widely spoken
| language in the world as well as being a richer and infinitely better
| structured language than English.
_____
Let's see,
Chinese
Spanish?
English?
Hindi?
Arabic?
French?
Russian?
Portuguese.
Hi Phil
Actually, English is apparently second.
Check out this link: http://www.infoplease.com/ipa/A0775272.html
I just can't figure out why I get so much spam from Brazil - I've worked in
Bolivia and Columbia, but never Brazil. I guess when sending spam is free,
it does not matter if the recipient can read the message.
Interestingly, I am in Brazil yet rarely receive spam from this
country. Rather the majority tend to come from Africa with offers of
exhorbitant sums of money.
And English is a very rich language - and it should be - English has adopted
words from more languages than perhaps any other. Unfortunately it as also
adopted a few rules from this one, that one, and the other. Logical it
isn't. I did study Latin - now that was a logical language, but WAY too
many noun and verb forms.
I am not at all disputing the fact that English is a rich language;
it's just that in my humble and highly ignorable opinion, Portuguese is
richer.
I will take your suggestion and actually try to read some of the Portuguese
language spam; though I guess that spam is not really the place to see good
use of language B^)
Aproveite e boa sorte
Paul
G
Guest
Gordon or anyone:
Thanks for the info on defragging. However, I would like to get an answer on
something weird with my defragger. A few months ago, my computer suffered a
shutdown and crash. I had to replace it. I recall defragging and noticing -
over time - that the "red" bars (the fractured ends of stuff) became almost
totally a large RED BAR, like the defragometer was showing the user (me) that
things weren't going right somewhere in my system. As I mentioned, soon after
I noticed this red bar grow to about thumbnail size (EEK!), the thing
crashed.
My question on defragging is this: I have read the help files, but I'd like
to hear some tech-in-person tell me just exactly I can glean from my
computer's health by looking at the defragger's parameters, reading its blue,
green, and red bars. Last time I saw the red bar grow over about a year's
time, I had a system crash.
I'd like to add to the previous questioner and to Gordon, the answerer: I
check my defragger about every three weeks or so. I have it analyzed with the
click of a button, and if the defragger says you don't need to, then I don't.
I have another question but I'll write it separately. Thank you to all for
your time, patience, and kindness!
about defragging frequency:
Thanks for the info on defragging. However, I would like to get an answer on
something weird with my defragger. A few months ago, my computer suffered a
shutdown and crash. I had to replace it. I recall defragging and noticing -
over time - that the "red" bars (the fractured ends of stuff) became almost
totally a large RED BAR, like the defragometer was showing the user (me) that
things weren't going right somewhere in my system. As I mentioned, soon after
I noticed this red bar grow to about thumbnail size (EEK!), the thing
crashed.
My question on defragging is this: I have read the help files, but I'd like
to hear some tech-in-person tell me just exactly I can glean from my
computer's health by looking at the defragger's parameters, reading its blue,
green, and red bars. Last time I saw the red bar grow over about a year's
time, I had a system crash.
I'd like to add to the previous questioner and to Gordon, the answerer: I
check my defragger about every three weeks or so. I have it analyzed with the
click of a button, and if the defragger says you don't need to, then I don't.
I have another question but I'll write it separately. Thank you to all for
your time, patience, and kindness!
about defragging frequency:
F
Fuzzy Logic
Gordon or anyone:
Thanks for the info on defragging. However, I would like to get an
answer on something weird with my defragger. A few months ago, my
computer suffered a shutdown and crash. I had to replace it. I recall
defragging and noticing - over time - that the "red" bars (the fractured
ends of stuff) became almost totally a large RED BAR, like the
defragometer was showing the user (me) that things weren't going right
somewhere in my system. As I mentioned, soon after I noticed this red
bar grow to about thumbnail size (EEK!), the thing crashed.
My question on defragging is this: I have read the help files, but I'd
like to hear some tech-in-person tell me just exactly I can glean from
my computer's health by looking at the defragger's parameters, reading
its blue, green, and red bars. Last time I saw the red bar grow over
about a year's time, I had a system crash.
Fragmented files should not cause a system to crash. You will take a very slight performance hit accessing
fragmented files and that's about it.
J
JS
The red bars indicate a file or files that a fragmented. Some Windows files
can not be defragmented while Windows is running, like the pagefile,
registry, event logs, Etc.
JS
can not be defragmented while Windows is running, like the pagefile,
registry, event logs, Etc.
JS
P
Pappion
I was always told to "Defrag anyway..." even if the window says it doesn't need it, and to always do so in Safe Mode. I then save the results in my "Computer" folder in My Documents to keep a record, since I'm not absolutely certain what I'm looking at, or interpreting.
The red bars indicate a file or files that a fragmented. Some Windows files
can not be defragmented while Windows is running, like the pagefile,
registry, event logs, Etc.
JS
The red bars indicate a file or files that a fragmented. Some Windows files
can not be defragmented while Windows is running, like the pagefile,
registry, event logs, Etc.
JS