Do disk defraggers check file systems first?
alfo
system integrity check (like XP's CHKDSK) before they start moving
data around?
I'm thinking of defraggers like Diskeeper and PerfectDisk as well as
XP's own defragger.
Ato_Zee
If there is a problem then their response is generally undefined.
There are a whole range of disk data integrity problems.
Some defraggers produce an error code for some problems
and will not try to defragment the drive.
At that point you fall back on MS$ product to see if it
can repair, or repair after a restart, which assumes that
the system will boot after the restart.
If it is a failing drive then you may be digging a bigger hole,
try to image, if that fails it may be a one shot
attempt to copy as much as you can. You try to
copy blocks of files, such as one folder at a time,
get an error unable to copy abc.xyz, delete the file
then carry on.
Of course for this you have to have a drive to copy to.
An eSATA or USB does not need a reboot, which may
save the day.
If the system drive is failing then you may not get
that far.
NTFS seems to be more robust than FAT and I've only
had a few data integrity problems, usually the drive
goes tits up without prior warning.
At which point you reach for your True Image (or
whichever you use) recovery disk and think about a
replacement drive.
You can of course create a file integrity problem
on a perfectly good drive, such as a dual boot attempt
going pearshaped, and you get the no system
message. Use image restore and have another go.
With tried and tested backups you are pretty fireproof,
and restore takes minutes. Rebuilding the system
and reinstalling all your software can take days,
and of course you have lost a lot of work, emails,
and vital stuff on the dead drive.
There are a few utilities that can seek to recover
seemingly lost or corrupt data.
Joep
news:%XIym.4530$xd4....@newsfe30.ams2...
He only asked if defraggers checked a volume prior to moving data. So,
yes/no will do.
Ian D
"alfo" <al...@invalid.com> wrote in message
news:Xns9C9C913...@newsfarm.ams2.highwinds-media.com...
Any defrag tools I have used since DOS 3.2 do a file system integrity
check, then give an error and stop the defrag if there's a problem.
The current one's I use are Diskeeper, and the XP and Vista
defragmenters. The error messages aren't very explicit, but a
chkdsk /f usually fixes any reported errors.
Ato_Zee
On 6-Oct-2009, "Joep" <avai...@request.nl> wrote:
> He only asked if defraggers checked a volume prior to moving data. So,
> yes/no will do.
OP generalised, there are many defraggers, I pointed out that
there is no consistency, either within any one of them, it
depends on the type of data integrety error, or between
how different defraggers handle the problem.
One I met compounded the problem, by seemingly
duplicating, without resolving, the corruption first.
There is no black and white, yes/no answer.
No defragger can cope with loss of data integrity on
a failing drive.
Defragging if of questionable value and the MS$ utility
does a fair job. Smart placement is just bells and
whistles.
Better to spend your money on backup than
defragging.
sidewinder
Yes, I believe they do. AFAIK, the windows defrag API developed jointly
by Diskeeper (excellent defragger BTW) and Microsoft has provisions for
checking the dirty bit on the volume before initiating a defrag. All
defraggers that use the API will utilize that. That's why some users get
a "Cannot defrag, chkdsk is scheduled to run etc" message when they
attempt to defrag a dirty file system. The defraggers themselves don't
run any chkdsk scans by default AFAIK, they just check the bit, though
some may have the option to do a full chkdsk before each defrag.
Joep
>
> On 6-Oct-2009, "Joep" <avai...@request.nl> wrote:
>
>> He only asked if defraggers checked a volume prior to moving data. So,
>> yes/no will do.
>
> OP generalised, there are many defraggers, I pointed out that
> there is no consistency, either within any one of them, it
> depends on the type of data integrety error, or between
> how different defraggers handle the problem.
He didn't ask for defraggers to fix things.
> One I met compounded the problem, by seemingly
> duplicating, without resolving, the corruption first.
> There is no black and white, yes/no answer.
Well, some do/ some don't CHECK.
> No defragger can cope with loss of data integrity on
> a failing drive.
No, that wasn't the question.
> Defragging if of questionable value and the MS$ utility
> does a fair job.
No it isn't
Smart placement is just bells and
> whistles.
No it isn't
> Better to spend your money on backup than
> defragging.
You don't have to spent money on it
Ato_Zee
On 7-Oct-2009, "Joep" <avai...@request.nl> wrote:
> >> He only asked if defraggers checked a volume prior to moving data. So,
> >> yes/no will do.
You can only say yes or no for a specific defragger, but not
for defraggers as a generalisation.
> He didn't ask for defraggers to fix things.
If OP is not interested in fixing things the query has no
meaning. Concern about checking the volume implies
concern about data integrity.
> Well, some do/ some don't CHECK.
As I said there is no yes/no answer.
> > No defragger can cope with loss of data integrity on
> > a failing drive.
>
> No, that wasn't the question.
So you are suggesting that we say that all defraggers
check the volume for integrity before defragging.
Commit yourself to yes or no, since you are so
concerned with an absolute definitive answer.
> > Defragging if of questionable value and the MS$ utility
> > does a fair job.
>
> No it isn't
Oh do tell us why
> Smart placement is just bells and
> > whistles.
>
> No it isn't
So tell us how smart placement makes jobs
run faster.
I have yet to see any improvement in processing
time for processor intensive jobs as a result
of Smart Placement.
Performance is more a hardware issue than where
the data is on the drive.
> > Better to spend your money on backup than
> > defragging.
>
> You don't have to spent money on it
But some utilities make life easier.
And in order to backup you have to spend money
on one or more backup drives, or on optical
media. What makes you think you don't have
to spend money? Perhaps you are one of those
who relies on a recovery partition, then comes here
asking what do I do, my drive has failed.
Joep
>
> On 7-Oct-2009, "Joep" <avai...@request.nl> wrote:
>
>> >> He only asked if defraggers checked a volume prior to moving data. So,
>> >> yes/no will do.
>
> You can only say yes or no for a specific defragger, but not
> for defraggers as a generalisation.
>
>> He didn't ask for defraggers to fix things.
>
> If OP is not interested in fixing things the query has no
> meaning. Concern about checking the volume implies
> concern about data integrity.
>
>> Well, some do/ some don't CHECK.
>
> As I said there is no yes/no answer.
>
>> > No defragger can cope with loss of data integrity on
>> > a failing drive.
>>
>> No, that wasn't the question.
>
> So you are suggesting that we say that all defraggers
> check the volume for integrity before defragging.
No, I am not suggesting that.
>
> Commit yourself to yes or no, since you are so
> concerned with an absolute definitive answer.
It's not about a definitive answer at all.
>
>> > Defragging if of questionable value and the MS$ utility
>> > does a fair job.
>>
>> No it isn't
>
> Oh do tell us why
Why?
>
>> Smart placement is just bells and
>> > whistles.
>>
>> No it isn't
>
> So tell us how smart placement makes jobs
> run faster.
Define 'jobs'
> I have yet to see any improvement in processing
> time for processor intensive jobs as a result
> of Smart Placement.
> Performance is more a hardware issue than where
> the data is on the drive.
>
>> > Better to spend your money on backup than
>> > defragging.
>>
>> You don't have to spent money on it
>
> But some utilities make life easier.
> And in order to backup you have to spend money
> on one or more backup drives, or on optical
> media. What makes you think you don't have
> to spend money? Perhaps you are one of those
> who relies on a recovery partition, then comes here
> asking what do I do, my drive has failed.
I am saying that a defragger that goes beyond that MS bult in defraggers
don"t have to cost money.
Your problem is, that you can't read and that makes this discussion useless.
Ato_Zee
On 7-Oct-2009, "Joep" <avai...@request.nl> wrote:
> >> Smart placement is just bells and
> >> > whistles.
> >>
> >> No it isn't
It is bells and whistles because it only benefits the
defragger by placing infrequently changed or accessed
files at the start of the drive, in non-fragmented
blocks. Where they do not get fragmented, so do
net repeatedly have to be defraged at each
defragmentation cycle.
The free MS utility does an adequate job.
System performance is a hardware issue,
Drive cache size, spin speed, access time,
pagefile optimisation, and a few other variables.
Try a few tests for yourself on drives that have
only been defraged with the MS utility, and
then on drives that have been detraged with
one of the cited utilities that has Smart Placement.
> I am saying that a defragger that goes beyond that
>MS bult in defraggers
> don"t have to cost money.
And is unlikely to yield any performance improvement,
stick with the MS one and invest in backup media.
Better use of your money.
Joep
>
> On 7-Oct-2009, "Joep" <avai...@request.nl> wrote:
>
>> >> Smart placement is just bells and
>> >> > whistles.
>> >>
>> >> No it isn't
>
> It is bells and whistles because it only benefits the
> defragger by placing infrequently changed or accessed
> files at the start of the drive, in non-fragmented
> blocks.
huh? infrequently used files at the start of the drive?
> Where they do not get fragmented, so do
> net repeatedly have to be defraged at each
> defragmentation cycle.
> The free MS utility does an adequate job.
>
> System performance is a hardware issue,
> Drive cache size, spin speed, access time,
> pagefile optimisation, and a few other variables.
Like fragmentation and placement on disk
> Try a few tests for yourself on drives that have
> only been defraged with the MS utility, and
> then on drives that have been detraged with
> one of the cited utilities that has Smart Placement.
Done that
>
>> I am saying that a defragger that goes beyond that
>>MS bult in defraggers
>> don"t have to cost money.
>
> And is unlikely to yield any performance improvement,
And thats where you are wrong
> stick with the MS one and invest in backup media.
> Better use of your money.
The money isn't an issue as stated before because there are free ones.
Ato_Zee
On 9-Oct-2009, "Joep" <avai...@request.nl> wrote:
> > System performance is a hardware issue,
> > Drive cache size, spin speed, access time,
> > pagefile optimisation, and a few other variables.
>
> Like fragmentation and placement on disk
Not so, the drive can more than adequately cope
with fragmentation. With adequate RAM drive
access is not an issue. Just check your
page faults with an MS defrag optimised drive
versus one with Smart Placement, no difference.
No difference either in Sandra benchmarks.
> > stick with the MS one and invest in backup media.
> > Better use of your money.
>
> The money isn't an issue as stated before because
> there are free ones.
Free media?
Joep
>
> On 9-Oct-2009, "Joep" <avai...@request.nl> wrote:
>
>> > System performance is a hardware issue,
>> > Drive cache size, spin speed, access time,
>> > pagefile optimisation, and a few other variables.
>>
>> Like fragmentation and placement on disk
>
> Not so, the drive can more than adequately cope
> with fragmentation.
Ah, so a drive copes with fragmentation itself?
> With adequate RAM drive
> access is not an issue.
At one point a file has to be read from disk /written to disk. No matter the
amount of memory a fragmented file will take longer than an unfragmented
file placed near the start of the disk.
> Just check your
> page faults with an MS defrag optimised drive
> versus one with Smart Placement, no difference.
File fragmentation is not limited to paging. It is unclear to me what you're
trying to argue here. You're constantly mixing things up. See where you got
us from the simple question 'do defraggers check the file system' all the
way here.
Joep
>
> On 7-Oct-2009, "Joep" <avai...@request.nl> wrote:
>
>> >> He only asked if defraggers checked a volume prior to moving data. So,
>> >> yes/no will do.
>
> You can only say yes or no for a specific defragger, but not
> for defraggers as a generalisation.
>
>> He didn't ask for defraggers to fix things.
>
> If OP is not interested in fixing things the query has no
> meaning. Concern about checking the volume implies
> concern about data integrity.
Of course it has. He's possibly afraid a defragger may corrupt a file system
in inconsistent state. That's something entirely different than asking a
defragger to fix corruption.
Ato_Zee
On 9-Oct-2009, "Joep" <avai...@request.nl> wrote:
> He's possibly afraid a defragger may corrupt a file system
> in inconsistent state. That's something entirely different than asking a
> defragger to fix corruption
There are defraggers that will further corrupt a file system
that is in an inconsistent state.
There is however no comparison checkbox for
defraggers. With ticks or crosses for various types
of corruption/inconsistency of the file system.
All should stop with an explanation if they find an
inconsistency, many don't.
I've seen defraggers that stop if the mirror MFT
is inconsistent, others ignore it.
Some try to move cross linked files, others stop.
Some duplicate orphaned files in the defrag
process, others ignore them.
So as I pointed out there is no yes/no answer
unless you are very specific about what defragger
you are referring to and what inconsistencies in
the file system you are concerned about.
The MS$ one catches most inconsistencies and
suggests a defrag/repair at the next reboot.
If it reports a repair log then it is adviseable
to check that the mirror MFT is consistent
with the master MFT, frequently, after MS$ has
done its repair these are inconsistent.
CHKDSK seems to have problems coping with
inconsistencies between the MFT and the
mirror MFT.
Which is why you need a proven and tested
backup system.
Rod Speed
> Ato_Zee <ato...@hotmail.com> wrote
>> Joep <avai...@request.nl> wrote
>>>> System performance is a hardware issue,
>>>> Drive cache size, spin speed, access time,
>>>> pagefile optimisation, and a few other variables.
>>> Like fragmentation and placement on disk
>> Not so, the drive can more than adequately cope with fragmentation.
> Ah, so a drive copes with fragmentation itself?
He didnt say that.
>> With adequate RAM drive access is not an issue.
> At one point a file has to be read from disk /written to disk.
You quite sure you aint one of those rocket scientist fellas ?
> No matter the amount of memory a fragmented file will take longer than an unfragmented file placed near the start of
> the disk.
Wrong when its a media file and the access to the
file is entirely dependant on the media play speed.
Fragmentation is completely irrelevant to how long it takes to move thru the file.
Joep
>
> On 9-Oct-2009, "Joep" <avai...@request.nl> wrote:
>
>> He's possibly afraid a defragger may corrupt a file system
>> in inconsistent state. That's something entirely different than asking a
>> defragger to fix corruption
>
> There are defraggers that will further corrupt a file system
> that is in an inconsistent state.
> There is however no comparison checkbox for
> defraggers. With ticks or crosses for various types
> of corruption/inconsistency of the file system.
> All should stop with an explanation if they find an
> inconsistency, many don't.
Yes, so this finally answers OP's question.
Joep
news:7ja4mmF...@mid.individual.net...
> Joep wrote
>> Ato_Zee <ato...@hotmail.com> wrote
>>> Joep <avai...@request.nl> wrote
>
>>>>> System performance is a hardware issue,
>>>>> Drive cache size, spin speed, access time,
>>>>> pagefile optimisation, and a few other variables.
>
>>>> Like fragmentation and placement on disk
>
>>> Not so, the drive can more than adequately cope with fragmentation.
>
>> Ah, so a drive copes with fragmentation itself?
>
> He didnt say that.
It's more productive if you then try to explain to me what it is he's
saying.
>
>>> With adequate RAM drive access is not an issue.
>
>> At one point a file has to be read from disk /written to disk.
>
> You quite sure you aint one of those rocket scientist fellas ?
>
>> No matter the amount of memory a fragmented file will take longer than an
>> unfragmented file placed near the start of the disk.
>
> Wrong when its a media file and the access to the
> file is entirely dependant on the media play speed.
Yes, and so?
Michael Cecil
O&O Defrag can be set to run a check of the filesystem before starting.
--
Michael Cecil
http://home.roadrunner.com/~macecil/
http://home.roadrunner.com/~safehex/
http://home.roadrunner.com/~macecil/hackingw7/
Rod Speed
> Rod Speed <rod.sp...@gmail.com> wrote
>>>>>> System performance is a hardware issue,
>>>>>> Drive cache size, spin speed, access time,
>>>>>> pagefile optimisation, and a few other variables.
>>>>> Like fragmentation and placement on disk
>>>> Not so, the drive can more than adequately cope with fragmentation.
>>> Ah, so a drive copes with fragmentation itself?
>> He didnt say that.
> It's more productive if you then try to explain to me what it is he's saying.
It makes a lot more sense for him to do that himself if he wants to.
>>>> With adequate RAM drive access is not an issue.
>>> At one point a file has to be read from disk /written to disk.
>> You quite sure you aint one of those rocket scientist fellas ?
>>> No matter the amount of memory a fragmented file will take longer
>>> than an unfragmented file placed near the start of the disk.
>> Wrong when its a media file and the access to the
>> file is entirely dependant on the media play speed.
> Yes, and so?
So you were just plain wrong.
Joep
> Joep wrote
>> Rod Speed <rod.sp...@gmail.com> wrote
>>> Joep wrote
>>>> Ato_Zee <ato...@hotmail.com> wrote
>>>>> Joep <avai...@request.nl> wrote
>
>>>>>>> System performance is a hardware issue,
>>>>>>> Drive cache size, spin speed, access time,
>>>>>>> pagefile optimisation, and a few other variables.
>
>>>>>> Like fragmentation and placement on disk
>
>>>>> Not so, the drive can more than adequately cope with fragmentation.
>
>>>> Ah, so a drive copes with fragmentation itself?
>
>>> He didnt say that.
>
>> It's more productive if you then try to explain to me what it is he's
>> saying.
>
> It makes a lot more sense for him to do that himself if he wants to.
Well, why then say 'he didnt say that' in the first place.
>
>>>>> With adequate RAM drive access is not an issue.
>
>>>> At one point a file has to be read from disk /written to disk.
>
>>> You quite sure you aint one of those rocket scientist fellas ?
>
>>>> No matter the amount of memory a fragmented file will take longer
>>>> than an unfragmented file placed near the start of the disk.
>
>>> Wrong when its a media file and the access to the
>>> file is entirely dependant on the media play speed.
>
>> Yes, and so?
>
> So you were just plain wrong.
Well, if all you do is play your media files all day then maybe, assuming
your statement is correct in the first place.
Ato_Zee
On 11-Oct-2009, "Joep" <avai...@request.nl> wrote:
> >>>>> Not so, the drive can more than adequately cope with fragmentation.
> >
> >>>> Ah, so a drive copes with fragmentation itself?
The drive has the MFT and its mirror, It knows wher the
requested data is, and will deliver files/data within the time
given in its spec. Drives are slow mechanical
devices as compared with the purely electronic parts of a
system.
Many assert that it is not worth defragging as it produces
no discernable improvement in system performance.
Much like registry cleaners.
alfo
Hello Joep. I'm the OP. I want to avoid making the data in my
partitons inaccessible by defragging if the defragger did not
ensure file system integrity before it started work.
FWIW I use PerfectDisk (it's now at v.10 but I use v.7).
Out of interest, does DiskTune do all the checking which Checkdsk
does? I know your website says "it checks the volume state prior
to defragmentation" but I wasn't sure if that was equivalent to
Diskchk. Thanks.
alfo
Sorry to have read your replies sooner. Thanks for the info. I
asumed a Checkdisk was always being performed whenever I used my
PerfectDisk but I wasn't sure. From what you say I shouldn't rely on
a defragger doing a check of file system integrity. Thanks.
Joep
>
> On 11-Oct-2009, "Joep" <avai...@request.nl> wrote:
>
>> >>>>> Not so, the drive can more than adequately cope with fragmentation.
>> >
>> >>>> Ah, so a drive copes with fragmentation itself?
>
> The drive has the MFT and its mirror, It knows wher the
> requested data is, and will deliver files/data within the time
> given in its spec.
Yes, it is bloody obvious it knows where the data is, that's the whole idea
isn't it? FYI, the MFT mirror isn't used for this and the mirror isn't what
it suggests it is (a complete mirror). What spec? Even if 'it' knows where
the data is, it still has to read it from the disk.
> Drives are slow mechanical
> devices as compared with the purely electronic parts of a
> system.
Yes.
> Many assert that it is not worth defragging as it produces
> no discernable improvement in system performance.
Well, they're wrong. One could argue that the improvement ain't that big of
a deal, that's open for discussion.
> Much like registry cleaners.
Utterly different beasts.
Joep
news:Xns9CA17F8...@newsfarm.ams2.highwinds-media.com...
>>>
>>>> He didn't ask for defraggers to fix things.
>>>
>>> If OP is not interested in fixing things the query has no
>>> meaning. Concern about checking the volume implies
>>> concern about data integrity.
>>
>> Of course it has. He's possibly afraid a defragger may corrupt
>> a file system in inconsistent state. That's something entirely
>> different than asking a defragger to fix corruption.
>>
>
> Hello Joep. I'm the OP. I want to avoid making the data in my
> partitons inaccessible by defragging if the defragger did not
> ensure file system integrity before it started work.
>
That was that I figured.
> FWIW I use PerfectDisk (it's now at v.10 but I use v.7).
>
> Out of interest, does DiskTune do all the checking which Checkdsk
> does?
Nope. Orginally I did, check if dirty bit was set (using chkdsk), but I
figured that it was wiser to have chkdsk do the repair instead of suggesting
that it was DiskTune doing the fixing of the file system. Currently I only
check the dirty bit (I think thats what the Vista defragger does as well).
However, defragging using the defrag API is harmless even if file system is
dirty.
Ato_Zee
On 11-Oct-2009, "Joep" <avai...@request.nl> wrote:
> What spec?
Drive mfrs give access time specs.
> Even if 'it' knows where
> the data is, it still has to read it from the disk.
Into its buffer. All that defragging does is ensure that it can
do this as a synchronous read.
If you want your data delivered faster buy a server drive
with high spin speed, a larger cache than consumer level
drives, and think SCSI or RAID striping.
Then get yourself an Intel Extreme Processor for
its larger on board cache.
.
Rod Speed
> Rod Speed <rod.sp...@gmail.com> wrote
>> Joep wrote
>>> Rod Speed <rod.sp...@gmail.com> wrote
>>>> Joep wrote
>>>>> Ato_Zee <ato...@hotmail.com> wrote
>>>>>> Joep <avai...@request.nl> wrote
>>>>>>>> System performance is a hardware issue,
>>>>>>>> Drive cache size, spin speed, access time,
>>>>>>>> pagefile optimisation, and a few other variables.
>>>>>>> Like fragmentation and placement on disk
>>>>>> Not so, the drive can more than adequately cope with fragmentation.
>>>>> Ah, so a drive copes with fragmentation itself?
>>>> He didnt say that.
>>> It's more productive if you then try to explain to me what it is he's saying.
>> It makes a lot more sense for him to do that himself if he wants to.
> Well, why then say 'he didnt say that' in the first place.
Because he didnt say that.
>>>>>> With adequate RAM drive access is not an issue.
>>>>> At one point a file has to be read from disk /written to disk.
>>>> You quite sure you aint one of those rocket scientist fellas ?
>>>>> No matter the amount of memory a fragmented file will take longer than an unfragmented file placed near the start
>>>>> of the disk.
>>>> Wrong when its a media file and the access to the
>>>> file is entirely dependant on the media play speed.
>>> Yes, and so?
>> So you were just plain wrong.
> Well, if all you do is play your media files all day then maybe,
> assuming your statement is correct in the first place.
Corse its correct.
And there are plenty of other examples where fragmention
has no effect on real world file use too, most obviously
with non serial access to files like with databases etc.
In fact there arent very many situations where the speed
of serial access to large files happens much anymore.
The most common situation now remaining is file copying
and it makes a lot more sense to not copy large files around
instead. Put them where they need to be in the first place.
Even with backup, the extra time that fragmentation can
produce is largely irrelevant because anyone with even
half a clue does backup in the background anyway.
Rod Speed
> "Ato_Zee" <ato...@hotmail.com> schreef in bericht
> news:i6jAm.21316$SO7....@newsfe15.ams2...
>>
>> On 11-Oct-2009, "Joep" <avai...@request.nl> wrote:
>>
>>>>>>>> Not so, the drive can more than adequately cope with
>>>>>>>> fragmentation.
>>>>
>>>>>>> Ah, so a drive copes with fragmentation itself?
>>
>> The drive has the MFT and its mirror, It knows wher the
>> requested data is, and will deliver files/data within the time
>> given in its spec.
>
> Yes, it is bloody obvious it knows where the data is, that's the
> whole idea isn't it? FYI, the MFT mirror isn't used for this and the
> mirror isn't what it suggests it is (a complete mirror). What spec?
> Even if 'it' knows where the data is, it still has to read it from
> the disk.
>> Drives are slow mechanical devices as compared with the purely electronic parts of a system.
> Yes.
>> Many assert that it is not worth defragging as it produces
>> no discernable improvement in system performance.
> Well, they're wrong.
Nope, not with most normal desktop PC use.
> One could argue that the improvement ain't that big of a deal, that's open for discussion.
Its also open for discussion just how much serial access to
large files there is on most desktop PCs that isnt media files
with which the speed of access is entirely determined by the
media speed, so fragments are completely invisible speed wise.
>> Much like registry cleaners.
> Utterly different beasts.
But just as pointless system performance wise with most desktop systems.
Joep
> Joep wrote
>> Rod Speed <rod.sp...@gmail.com> wrote
>>> Joep wrote
>>>> Rod Speed <rod.sp...@gmail.com> wrote
>>>>> Joep wrote
>>>>>> Ato_Zee <ato...@hotmail.com> wrote
>>>>>>> Joep <avai...@request.nl> wrote
>
>>>>>>>>> System performance is a hardware issue,
>>>>>>>>> Drive cache size, spin speed, access time,
>>>>>>>>> pagefile optimisation, and a few other variables.
>
>>>>>>>> Like fragmentation and placement on disk
>
>>>>>>> Not so, the drive can more than adequately cope with fragmentation.
>
>>>>>> Ah, so a drive copes with fragmentation itself?
>
>>>>> He didnt say that.
>
>>>> It's more productive if you then try to explain to me what it is he's
>>>> saying.
>
>>> It makes a lot more sense for him to do that himself if he wants to.
>
>> Well, why then say 'he didnt say that' in the first place.
>
> Because he didnt say that.
he did
>
>>>>>>> With adequate RAM drive access is not an issue.
>
>>>>>> At one point a file has to be read from disk /written to disk.
>
>>>>> You quite sure you aint one of those rocket scientist fellas ?
>
>>>>>> No matter the amount of memory a fragmented file will take longer
>>>>>> than an unfragmented file placed near the start of the disk.
>
>>>>> Wrong when its a media file and the access to the
>>>>> file is entirely dependant on the media play speed.
>
>>>> Yes, and so?
>
>>> So you were just plain wrong.
>
>> Well, if all you do is play your media files all day then maybe,
>> assuming your statement is correct in the first place.
>
> Corse its correct.
>
> And there are plenty of other examples where fragmention
> has no effect on real world file use too, most obviously
> with non serial access to files like with databases etc.
And there are also real world examples where file placement and
fragmentation does have affect.
>
> In fact there arent very many situations where the speed
> of serial access to large files happens much anymore.
>
> The most common situation now remaining is file copying
> and it makes a lot more sense to not copy large files around
> instead. Put them where they need to be in the first place.
Aha, you quite sure you aint one of those rocket scientist fellas ?
Joep
> Joep wrote:
>> "Ato_Zee" <ato...@hotmail.com> schreef in bericht
>> news:i6jAm.21316$SO7....@newsfe15.ams2...
>>>
>>> On 11-Oct-2009, "Joep" <avai...@request.nl> wrote:
>>>
>>>>>>>>> Not so, the drive can more than adequately cope with
>>>>>>>>> fragmentation.
>>>>>
>>>>>>>> Ah, so a drive copes with fragmentation itself?
>>>
>>> The drive has the MFT and its mirror, It knows wher the
>>> requested data is, and will deliver files/data within the time
>>> given in its spec.
>>
>> Yes, it is bloody obvious it knows where the data is, that's the
>> whole idea isn't it? FYI, the MFT mirror isn't used for this and the
>> mirror isn't what it suggests it is (a complete mirror). What spec?
>> Even if 'it' knows where the data is, it still has to read it from
>> the disk.
>
>>> Drives are slow mechanical devices as compared with the purely
>>> electronic parts of a system.
>
>> Yes.
>
>>> Many assert that it is not worth defragging as it produces
>>> no discernable improvement in system performance.
>
>> Well, they're wrong.
>
> Nope, not with most normal desktop PC use.
Then define normal desktop PC use. People I know turn off the PC at the end
of the day, and then when they turn it back on next day they're annoyed by
the huge amount of time it takes to start up Windows. Remedy: optimize the
file system, it has a huge impact. Those pcs are typically used for all
kinds of stuff (databases not being one of them), browsing, email, text
processing etc.. Programs are closed, opened again etc.. All kinds of stuff
that can be improved by defragmentation and disk optimization. often, when
they ask for my help cause the thing is so slow, it's the only thing I do,
run disk optimization, and they notice the difference, even i something as
simple as listing a large folder in explorer. I suppose that there will be
differences between an up to date, fast modern machine and one that has been
running for a few years. And if you reboot the thing only once a week then
boot optimization won't be that big of a deal.
>
>> One could argue that the improvement ain't that big of a deal, that's
>> open for discussion.
>
> Its also open for discussion just how much serial access to
> large files there is on most desktop PCs that isnt media files
> with which the speed of access is entirely determined by the
> media speed, so fragments are completely invisible speed wise.
>
>>> Much like registry cleaners.
>
>> Utterly different beasts.
>
> But just as pointless system performance wise with most desktop systems.
Well, I am afraid you are wrong (predicted answer: "fraid not"), but I know
you will never admit that.
>
>
Ato_Zee
On 11-Oct-2009, "Joep" <avai...@request.nl> wrote:
> People I know turn off the PC at the end
> of the day, and then when they turn it back on next day they're annoyed by
> the huge amount of time it takes to start up Windows.
That is not due to fragmentation, it is due to the number of processes
and services to be started.
By your argument a heavily used machine would be so fragmented
and slowed down by it to be unuseable by lunchtime.
You are trying to convince everyone to defrag several times a day.
Fragmentation wasn't an issue in the days of CP/M and isn't
today. You don't have to defrag TB drives every few hours.
Rod Speed
> Rod Speed <rod.sp...@gmail.com> wrote
>> Joep wrote
>>> Ato_Zee <ato...@hotmail.com> wrote
>>>>>>>>>> Not so, the drive can more than adequately cope with fragmentation.
>>>>>>>>> Ah, so a drive copes with fragmentation itself?
>>>> The drive has the MFT and its mirror, It knows wher the
>>>> requested data is, and will deliver files/data within the time
>>>> given in its spec.
>>> Yes, it is bloody obvious it knows where the data is, that's the
>>> whole idea isn't it? FYI, the MFT mirror isn't used for this and the
>>> mirror isn't what it suggests it is (a complete mirror). What spec?
>>> Even if 'it' knows where the data is, it still has to read it from the disk.
>>>> Drives are slow mechanical devices as compared with the purely
>>>> electronic parts of a system.
>>> Yes.
>>>> Many assert that it is not worth defragging as it produces
>>>> no discernable improvement in system performance.
>>> Well, they're wrong.
>> Nope, not with most normal desktop PC use.
> Then define normal desktop PC use.
Dont need to, the phase is obvious.
> People I know turn off the PC at the end of the day, and then when they turn it back on next day they're annoyed by
> the huge amount of time it takes to start up Windows.
Nothing to do with normal file fragmentation, essentially because few of
the OS files get very fragmented because they arent written that much.
> Remedy: optimize the file system, it has a huge impact.
Like hell it does.
And the later versions of Win optimise the location of files on the hard drive anyway.
> Those pcs are typically used for all kinds of stuff (databases not being one of them), browsing, email, text
> processing etc..
And very few of those do much serial access to large files except with media files.
> Programs are closed, opened again etc..
Those files arent significantly fragmented on normal desktop PCs.
> All kinds of stuff that can be improved by defragmentation and disk optimization.
Easy to claim. Pity you cant actually substantiate that claim.
> often, when they ask for my help cause the thing is so slow, it's the only thing I do, run disk optimization, and they
> notice the difference, even i something as simple as listing a large folder in explorer.
Thats the placebo effect. Have fun proving that with a proper double blind trial.
> I suppose that there will be differences between an up to date, fast modern machine and one that has been running for
> a few years. And if you reboot the thing only once a week then boot optimization won't be that big of a deal.
And fuck all of the boot time is due to file fragmentation.
>>> One could argue that the improvement ain't that big of a deal, that's open for discussion.
>> Its also open for discussion just how much serial access to
>> large files there is on most desktop PCs that isnt media files
>> with which the speed of access is entirely determined by the
>> media speed, so fragments are completely invisible speed wise.
>>>> Much like registry cleaners.
>>> Utterly different beasts.
>> But just as pointless system performance wise with most desktop systems.
> Well, I am afraid you are wrong
Easy to claim. How odd that you cant actually substantiate that claim.
Rod Speed
> Rod Speed <rod.sp...@gmail.com> wrote
>> Joep wrote
>>> Rod Speed <rod.sp...@gmail.com> wrote
>>>> Joep wrote
>>>>> Rod Speed <rod.sp...@gmail.com> wrote
>>>>>> Joep wrote
>>>>>>> Ato_Zee <ato...@hotmail.com> wrote
>>>>>>>> Joep <avai...@request.nl> wrote
>>>>>>>>>> System performance is a hardware issue,
>>>>>>>>>> Drive cache size, spin speed, access time,
>>>>>>>>>> pagefile optimisation, and a few other variables.
>>>>>>>>> Like fragmentation and placement on disk
>>>>>>>> Not so, the drive can more than adequately cope with fragmentation.
>>>>>>> Ah, so a drive copes with fragmentation itself?
>>>>>> He didnt say that.
>>>>> It's more productive if you then try to explain to me what it is he's saying.
>>>> It makes a lot more sense for him to do that himself if he wants to.
>>> Well, why then say 'he didnt say that' in the first place.
>> Because he didnt say that.
> he did
He didnt.
>>>>>>>> With adequate RAM drive access is not an issue.
>>>>>>> At one point a file has to be read from disk /written to disk.
>>>>>> You quite sure you aint one of those rocket scientist fellas ?
>>>>>>> No matter the amount of memory a fragmented file will take
>>>>>>> longer than an unfragmented file placed near the start of the disk.
>>>>>> Wrong when its a media file and the access to the
>>>>>> file is entirely dependant on the media play speed.
>>>>> Yes, and so?
>>>> So you were just plain wrong.
>>> Well, if all you do is play your media files all day then maybe,
>>> assuming your statement is correct in the first place.
>> Corse its correct.
>> And there are plenty of other examples where fragmention
>> has no effect on real world file use too, most obviously
>> with non serial access to files like with databases etc.
> And there are also real world examples where file placement and fragmentation does have affect.
Not with modern Win OSs that do file placement themselves.
>> In fact there arent very many situations where the speed
>> of serial access to large files happens much anymore.
>> The most common situation now remaining is file copying
>> and it makes a lot more sense to not copy large files around
>> instead. Put them where they need to be in the first place.
> Aha, you quite sure you aint one of those rocket scientist fellas ?
Cant even manage its own lines. Or anything else either.
Joep
>
> On 11-Oct-2009, "Joep" <avai...@request.nl> wrote:
>
>> People I know turn off the PC at the end
>> of the day, and then when they turn it back on next day they're annoyed
>> by
>> the huge amount of time it takes to start up Windows.
>
> That is not due to fragmentation, it is due to the number of processes
> and services to be started.
No, because if I optimize this file system it starts quicker. So I load the
same amount of services, change one parameter namely the location of the
files on the disk, and it loads faster.
> By your argument a heavily used machine would be so fragmented
> and slowed down by it to be unuseable by lunchtime.
> You are trying to convince everyone to defrag several times a day.
No I am not. Biggest gain is from optimization (file placement) and I do
that every few months.
> Fragmentation wasn't an issue in the days of CP/M and isn't
> today.
It still is an issue
> You don't have to defrag TB drives every few hours.
I agree.
alfo
Hello Joep. I should say I'm sorry for being ambiguous for writing
"Checkdsk and "Diskchk" when I meant "Dskchk".
I have 2 questions.
(1) Is the XP dirty bit set by events like a Dskchk and when the
system encounters a problem in accessing data? If so then it must
mean the dirty bit is not set if the system is unaware of a problem.
(2) By a "dirty" file system do you mean (a) one in which the dirty
bit has been set or do you mean (b) one in which the file system is
corrupt and the dirty bit may or may not have been set? IYSWIM.
I'm trying to find my way forward to understand how using the defrag
APIs can be harmless even if the file system is compromised.
Rod Speed
>>> People I know turn off the PC at the end of the day, and then when they turn it back on next day they're annoyed by
>>> the huge amount of time it takes to start up Windows.
>> That is not due to fragmentation, it is due to the number of processes and services to be started.
> No, because if I optimize this file system it starts quicker.
Easy to claim. You cant actually substantiate that claim.
> So I load the same amount of services, change one parameter namely the location of the files on the disk, and it loads
> faster.
Easy to claim. You cant actually substantiate that claim.
>> By your argument a heavily used machine would be so fragmented
>> and slowed down by it to be unuseable by lunchtime.
>> You are trying to convince everyone to defrag several times a day.
> No I am not. Biggest gain is from optimization (file placement) and I
> do that every few months.
>> Fragmentation wasn't an issue in the days of CP/M and isn't today.
> It still is an issue
Easy to claim. You cant actually substantiate that claim.
Joep
No actually it isn't, just try it for yourself.
>
>
>
Ato_Zee
On 12-Oct-2009, "Joep" <avai...@request.nl> wrote:
> >>> Fragmentation wasn't an issue in the days of CP/M and isn't today.
> >
> >> It still is an issue
> >
> > Easy to claim. You cant actually substantiate that claim.
>
> No actually it isn't, just try it for yourself.
I have, defragging makes no discernable difference. It's
juat that a lot of people are making a lot of money out
of defragging utilities, and pretending to be experts to
make money as computer consultants and repairers.
Hospitals, universities, most businesses, don't
routinely defrag, and their computers run perfectly
well without it. Manual front office operations continuously
process orders, holiday bookings, customer queries and
help desk operations, they aren't defragging all the time
their systems run perfectly well without it.
If you want to permanently boost performance then
go through system services one by one, many
that start automatically aren't really needed and should
be stopped, or set to start "on use". Then go through
apps that start on boot, followed by reducing the startup
delay timers, like the one that waits to see if you want
to start in safe mode.
You are a Snake Oil peddler with your exagerated claims
of a dramatic performance boost.
Even LanParty and online gamers continuously
shifting screens of graphics and large volumes of
data don't keep defragging all the time.
Joep
>
> On 12-Oct-2009, "Joep" <avai...@request.nl> wrote:
>
>> >>> Fragmentation wasn't an issue in the days of CP/M and isn't today.
>> >
>> >> It still is an issue
>> >
>> > Easy to claim. You cant actually substantiate that claim.
>>
>> No actually it isn't, just try it for yourself.
>
> I have, defragging makes no discernable difference.
I do not make money with it. I am not talking defragging, I am talking
optimizing for quite a few posts now. If you didn't get that by now, you're
thick. It does make a noticable difference (file placement, optimization).
Right here, on both PCs I use. What you have to say for the rest, I don't
care. If you defrag or not, I don't care.Iif anyone else defrags or not, I
don't care. I am not in a server environment, I don't care if they run it on
servers or not.
Waiting for the thing to boot bugs me. If I can bring that down even a
couple of seconds (but it's more than that) then for me that's significant
and worth it. I tested that and I do not need you or Rodless to confirm
that. To accomplish that I do not need to defrag 'all the time' as you put
it. Just once every 3 months is fine depending on software installed
(including service packs) during that period.
All apps I frequently use load faster after disk optimization. Instead of
the previous disk rattling and waiting, the disk is now quiet and the app is
up in no time. For me that's a significant improvement. I am happy now.
Joep
> Joep wrote
>> Rod Speed <rod.sp...@gmail.com> wrote
>>> Joep wrote
>>>> Rod Speed <rod.sp...@gmail.com> wrote
>>>>> Joep wrote
>>>>>> Rod Speed <rod.sp...@gmail.com> wrote
>>>>>>> Joep wrote
>>>>>>>> Ato_Zee <ato...@hotmail.com> wrote
>>>>>>>>> Joep <avai...@request.nl> wrote
>
>>>>>>>>>>> System performance is a hardware issue,
>>>>>>>>>>> Drive cache size, spin speed, access time,
>>>>>>>>>>> pagefile optimisation, and a few other variables.
>
>>>>>>>>>> Like fragmentation and placement on disk
>
>>>>>>>>> Not so, the drive can more than adequately cope with
>>>>>>>>> fragmentation.
>
>>>>>>>> Ah, so a drive copes with fragmentation itself?
>
>>>>>>> He didnt say that.
>
>>>>>> It's more productive if you then try to explain to me what it is he's
>>>>>> saying.
>
>>>>> It makes a lot more sense for him to do that himself if he wants to.
>
>>>> Well, why then say 'he didnt say that' in the first place.
>
>>> Because he didnt say that.
>
>> he did
>
> He didnt.
he did
>
>>>>>>>>> With adequate RAM drive access is not an issue.
>
>>>>>>>> At one point a file has to be read from disk /written to disk.
>
>>>>>>> You quite sure you aint one of those rocket scientist fellas ?
>
>>>>>>>> No matter the amount of memory a fragmented file will take
>>>>>>>> longer than an unfragmented file placed near the start of the disk.
>
>>>>>>> Wrong when its a media file and the access to the
>>>>>>> file is entirely dependant on the media play speed.
>
>>>>>> Yes, and so?
>
>>>>> So you were just plain wrong.
>
>>>> Well, if all you do is play your media files all day then maybe,
>>>> assuming your statement is correct in the first place.
>
>>> Corse its correct.
>
>>> And there are plenty of other examples where fragmention
>>> has no effect on real world file use too, most obviously
>>> with non serial access to files like with databases etc.
>
>> And there are also real world examples where file placement and
>> fragmentation does have affect.
>
> Not with modern Win OSs that do file placement themselves.
Well, if I can improve whatever the modern OS does, then file placement does
have effect.
>
>>> In fact there arent very many situations where the speed
>>> of serial access to large files happens much anymore.
>
>>> The most common situation now remaining is file copying
>>> and it makes a lot more sense to not copy large files around
>>> instead. Put them where they need to be in the first place.
>
>> Aha, you quite sure you aint one of those rocket scientist fellas ?
>
> Cant even manage its own lines. Or anything else either.
Lol! Such a simple mind, must be wonderful.
>
>
Rod Speed
Did that, you lied.
And it makes no sense to be doing a full reboot every day anyway.
If you do want to turn the system off every day, you should hibernate, not shut down.
Rod Speed
>>>>>> Fragmentation wasn't an issue in the days of CP/M and isn't today.
>>>>> It still is an issue
>>>> Easy to claim. You cant actually substantiate that claim.
>>> No actually it isn't, just try it for yourself.
>> I have, defragging makes no discernable difference.
> I do not make money with it. I am not talking defragging, I am talking optimizing for quite a few posts now.
You're lying now.
> If you didn't get that by now, you're thick.
And you are a pathological liar.
> It does make a noticable difference (file placement, optimization).
Like hell it does. And modern MS OSs do that anyway.
> Right here, on both PCs I use.
Doesnt make the HUGE DIFFERENCE you lied about previously.
Even with the worst file placement, the most that does is add
a couple of milliseconds to the head movement between files
and that is nothing in the total boot time of a curent MS OS.
> What you have to say for the rest, I don't care. If you defrag or not, I don't care.Iif anyone else defrags or not, I
> don't care. I am not in a server environment, I don't care if they run it on servers or not.
> Waiting for the thing to boot bugs me.
Then you should hibernate instead of shutting down, stupid.
> If I can bring that down even a couple of seconds (but it's more than that) then for me that's significant and worth
> it.
Then you should hibernate instead of shutting down, stupid.
> I tested that and I do not need you or Rodless to confirm that.
Pity you're so stupid that you havent even noticed that hibernating saves
a hell of a lot MORE in the startup time than file placement ever does.
> To accomplish that I do not need to defrag 'all the time' as you put it. Just once every 3 months is fine depending on
> software installed (including service packs) during that period.
Service packs dont come out at anything like that frequency and
software installed doesnt affect the placement of OS files either.
> All apps I frequently use load faster after disk optimization.
At most by a few mS. Thats nothing in app start time, liar.
> Instead of the previous disk rattling and waiting, the disk is now quiet and the app is up in no time.
Thanks for that completely superfluous proof that you are a pathological liar.
> For me that's a significant improvement.
Pity that hibernating instead of shutting down would save MUCH more.
> I am happy now.
Village eejuts usually are.
Rod Speed
>>>>>>>> He didnt say that.
>>> he did
>> He didnt.
> he did
He didnt.
>>>>>>>>>> With adequate RAM drive access is not an issue.
>>>>>>>>> At one point a file has to be read from disk /written to disk.
>>>>>>>> You quite sure you aint one of those rocket scientist fellas ?
>>>>>>>>> No matter the amount of memory a fragmented file will take
>>>>>>>>> longer than an unfragmented file placed near the start of the disk.
>>>>>>>> Wrong when its a media file and the access to the
>>>>>>>> file is entirely dependant on the media play speed.
>>>>>>> Yes, and so?
>>>>>> So you were just plain wrong.
>>>>> Well, if all you do is play your media files all day then maybe,
>>>>> assuming your statement is correct in the first place.
>>>> Corse its correct.
>>>> And there are plenty of other examples where fragmention
>>>> has no effect on real world file use too, most obviously
>>>> with non serial access to files like with databases etc.
>>> And there are also real world examples where file placement and fragmentation does have affect.
>> Not with modern Win OSs that do file placement themselves.
> Well, if I can improve whatever the modern OS does,
You cant.
> then file placement does have effect.
Nope, the mS or so saved is nothing in the time it takes to load that file.
>>>> In fact there arent very many situations where the speed
>>>> of serial access to large files happens much anymore.
>>>> The most common situation now remaining is file copying
>>>> and it makes a lot more sense to not copy large files around
>>>> instead. Put them where they need to be in the first place.
>>> Aha, you quite sure you aint one of those rocket scientist fellas ?
>> Cant even manage its own lines. Or anything else either.
> Lol! Such a simple mind, must be wonderful.
Never ever could bullshit and lie its way out of a wet paper bag.
Joep
>
>>> Easy to claim. You cant actually substantiate that claim.
>
>> No actually it isn't, just try it for yourself.
>
> Did that, you lied.
You didn't Rodless
>
> And it makes no sense to be doing a full reboot every day anyway.
>
> If you do want to turn the system off every day, you should hibernate, not
> shut down.
I shut it down.
>
>
Joep
> Joep wrote
>> Ato_Zee <ato...@hotmail.com> wrote
>>> Joep <avai...@request.nl> wrote
>
>>>>>>> Fragmentation wasn't an issue in the days of CP/M and isn't today.
>
>>>>>> It still is an issue
>
>>>>> Easy to claim. You cant actually substantiate that claim.
>
>>>> No actually it isn't, just try it for yourself.
>
>>> I have, defragging makes no discernable difference.
>
>> I do not make money with it. I am not talking defragging, I am talking
>> optimizing for quite a few posts now.
>
> You're lying now.
Oh?
>
>> If you didn't get that by now, you're thick.
>
> And you are a pathological liar.
Hahaha. Yes, I AM LYING!
>
>> It does make a noticable difference (file placement, optimization).
>
> Like hell it does. And modern MS OSs do that anyway.
>
>> Right here, on both PCs I use.
>
> Doesnt make the HUGE DIFFERENCE you lied about previously.
Well, actually it is huge.
>
> Even with the worst file placement, the most that does is add
> a couple of milliseconds to the head movement between files
> and that is nothing in the total boot time of a curent MS OS.
Try it and you will find you're wrong. You can continue repeating yourself,
but that doesn't change this fact that can be easily verified by anyone.
>
>> What you have to say for the rest, I don't care. If you defrag or not, I
>> don't care.Iif anyone else defrags or not, I don't care. I am not in a
>> server environment, I don't care if they run it on servers or not.
>
>> Waiting for the thing to boot bugs me.
>
> Then you should hibernate instead of shutting down, stupid.
He's calling names and we all know what that means
>
> Pity you're so stupid that you havent even noticed that hibernating saves
> a hell of a lot MORE in the startup time than file placement ever does.
Well, personal dislike, I only use it for laptop during lunchbreak, short
brakes.
>
>> To accomplish that I do not need to defrag 'all the time' as you put it.
>> Just once every 3 months is fine depending on software installed
>> (including service packs) during that period.
>
> Service packs dont come out at anything like that frequency and
> software installed doesnt affect the placement of OS files either.
Yeah, I meant the regular updates, sorry. No, software installed doesn't
affect OC boot, but if those are programs I frequently use, I want them
optimized as well.
>
>> All apps I frequently use load faster after disk optimization.
>
> At most by a few mS. Thats nothing in app start time, liar.
Well, it actually does Rod. Loading an app does may require Windows more
than just loading the app.
>
>> Instead of the previous disk rattling and waiting, the disk is now quiet
>> and the app is up in no time.
>
> Thanks for that completely superfluous proof that you are a pathological
> liar.
>
>> For me that's a significant improvement.
>
> Pity that hibernating instead of shutting down would save MUCH more.
What does hibernate do for app loading then?
>
>> I am happy now.
>
> Village eejuts usually are.
Even if so, that doesn't proof a thing.
Rod Speed
> Rod Speed <rod.sp...@gmail.com> wrote
>>>>>> Fragmentation wasn't an issue in the days of CP/M and isn't today.
>>>>> It still is an issue
>>>> Easy to claim. You cant actually substantiate that claim.
>>> No actually it isn't, just try it for yourself.
>> Did that, you lied.
> You didn't Rodless
You're lying, as always.
>> And it makes no sense to be doing a full reboot every day anyway.
>> If you do want to turn the system off every day, you should hibernate, not shut down.
> I shut it down.
Then you are a terminal fuckwit when hibernating saves a hell
of a lot more time on the startup than 'optimising' can ever do.
Rod Speed
>>>>>>>> Fragmentation wasn't an issue in the days of CP/M and isn't today.
>>>>>>> It still is an issue
>>>>>> Easy to claim. You cant actually substantiate that claim.
>>>>> No actually it isn't, just try it for yourself.
>>>> I have, defragging makes no discernable difference.
>>> I do not make money with it. I am not talking defragging, I am talking optimizing for quite a few posts now.
>> You're lying now.
> Oh?
Yep, even you should be able to see that there is no mention of optimising
in the two quotes now right at the top, you silly little pathological liar.
>>> If you didn't get that by now, you're thick.
>> And you are a pathological liar.
> Hahaha. Yes, I AM LYING!
Everyone can see for themselves what is in the first two quote now at the top of this post.
>>> It does make a noticable difference (file placement, optimization).
>> Like hell it does. And modern MS OSs do that anyway.
>>> Right here, on both PCs I use.
>> Doesnt make the HUGE DIFFERENCE you lied about previously.
> Well, actually it is huge.
Easy to claim. You cant actually substantiate that claim.
>> Even with the worst file placement, the most that does is add
>> a couple of milliseconds to the head movement between files
>> and that is nothing in the total boot time of a curent MS OS.
> Try it
Dont need to. Even someone as stupid as you should be able to
work out that the extra time for the longer seek with a poorly placed
file can never be more than a few mS with modern hard drives.
> and you will find you're wrong.
Just another of your lies.
> You can continue repeating yourself, but that doesn't change this fact that can be easily verified by anyone.
They can indeed, and proof that you are a pathological liar.
Not that that is any news to anyone at all.
>>> What you have to say for the rest, I don't care. If you defrag or not, I don't care.Iif anyone else defrags or not,
>>> I don't care. I am not in a server environment, I don't care if they run it on servers or not.
>>> Waiting for the thing to boot bugs me.
>> Then you should hibernate instead of shutting down, stupid.
> He's calling names
You're lying, again. Just an accurate characterisation, you silly little pathological liar.
> and we all know what that means
Yep, you've got done like a fucking dinner, as always.
>> Pity you're so stupid that you havent even noticed that hibernating saves a hell of a lot MORE in the startup time
>> than file placement ever does.
> Well, personal dislike, I only use it for laptop during lunchbreak, short brakes.
Thanks for that completely superfluous proof that you are a terminal fuckwit
when that saves FAR more startup time than 'optimisation' can ever do.
>>> To accomplish that I do not need to defrag 'all the time' as you
>>> put it. Just once every 3 months is fine depending on software
>>> installed (including service packs) during that period.
>> Service packs dont come out at anything like that frequency and
>> software installed doesnt affect the placement of OS files either.
> Yeah, I meant the regular updates, sorry.
They update fuck all of the OS files.
> No, software installed doesn't affect OC boot, but if those are programs I frequently use, I want them optimized as
> well.
Then you are a terminal fuckwit when hibernating saves
FAR more startup time than 'optimising' can ever do.
>>> All apps I frequently use load faster after disk optimization.
>> At most by a few mS. Thats nothing in app start time, liar.
> Well, it actually does Rod.
Easy to claim. You cant actually substantiate that claim.
> Loading an app does may require Windows more than just loading the app.
Still fuck all with each file.
Hibernating saves FAR more time.
Corse you are so stupid you dont hibernate.
>>> Instead of the previous disk rattling and waiting, the disk is now quiet and the app is up in no time.
>> Thanks for that completely superfluous proof that you are a pathological liar.
>>> For me that's a significant improvement.
>> Pity that hibernating instead of shutting down would save MUCH more.
> What does hibernate do for app loading then?
Everything when you arent stupid enough to shut down the app.
>>> I am happy now.
>> Village eejuts usually are.
> Even if so, that doesn't proof a thing.
Corse it does.
John Turco
>
> > Joep wrote
<edited for brevity>
> >> If you do want to turn the system off every day, you should
> >> hibernate, not shut down.
>
> > I shut it down.
>
> Then you are a terminal fuckwit when hibernating saves a hell
> of a lot more time on the startup than 'optimising' can ever
> do.
Hey, Rod, do you think "Joep" knows what ever happened to his
fellow denizen of the Netherlands...the foulest of fanatics,
Folkert Rienstra? Dat ol' Folksy ain't been around here, at
all, throughout 2009.
In fact, according to Google Groups </http://groups.google.com>,
the dreadful Dutchman's final Usenet post was on September 19,
2008; no longer does he plague >any< newsgroup, evidently.
Oh, and for your information, I'm hardly wailing about his
sudden disappearance. (Good riddance to bad rubbish, as the
saying goes.)
--
Cordially,
John Turco <jt...@concentric.net>
Paintings Pain and Pun <http://laughatthepain.blogspot.com>
Rod Speed
> Rod Speed wrote
>>> Joep wrote
>>>> If you do want to turn the system off every day, you should
>>>> hibernate, not shut down.
>>> I shut it down.
>> Then you are a terminal fuckwit when hibernating saves a hell
>> of a lot more time on the startup than 'optimising' can ever do.
> Hey, Rod, do you think "Joep" knows what ever happened to his
> fellow denizen of the Netherlands...the foulest of fanatics,
> Folkert Rienstra? Dat ol' Folksy ain't been around here, at
> all, throughout 2009.
He's the one that killed him off, because Fucknert
made snide remarks about his commercial activity.
> In fact, according to Google Groups </http://groups.google.com>,
> the dreadful Dutchman's final Usenet post was on September 19,
> 2008; no longer does he plague >any< newsgroup, evidently.
Yeah, the GFC saw the plug pulled on net access to his padded cell.
Heard the one about silver linings ?
> Oh, and for your information, I'm hardly wailing about his sudden disappearance.
I know you grovel in front of your Fucknert shrine, daily.
> (Good riddance to bad rubbish, as the saying goes.)
Indeed.