Do disk defraggers check file systems first?
in [Storage]
|
From: Rod Speed on 11 Oct 2009 15:30 Joep wrote: > "Ato_Zee" <ato_zee(a)hotmail.com> schreef in bericht > news:i6jAm.21316$SO7.3501(a)newsfe15.ams2... >> >> On 11-Oct-2009, "Joep" <available(a)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.
From: Joep on 11 Oct 2009 18:25 "Rod Speed" <rod.speed.aaa(a)gmail.com> schreef in bericht news:7jeq2tF34o2ejU1(a)mid.individual.net... > Joep wrote: >> "Ato_Zee" <ato_zee(a)hotmail.com> schreef in bericht >> news:i6jAm.21316$SO7.3501(a)newsfe15.ams2... >>> >>> On 11-Oct-2009, "Joep" <available(a)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. > >
From: Joep on 11 Oct 2009 18:28 "Rod Speed" <rod.speed.aaa(a)gmail.com> schreef in bericht news:7jepmcF34nn53U1(a)mid.individual.net... > Joep wrote >> Rod Speed <rod.speed.aaa(a)gmail.com> wrote >>> Joep wrote >>>> Rod Speed <rod.speed.aaa(a)gmail.com> wrote >>>>> Joep wrote >>>>>> Ato_Zee <ato_zee(a)hotmail.com> wrote >>>>>>> Joep <available(a)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 ?
From: Ato_Zee on 11 Oct 2009 18:49 On 11-Oct-2009, "Joep" <available(a)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.
From: Rod Speed on 11 Oct 2009 21:02
Joep wrote > Rod Speed <rod.speed.aaa(a)gmail.com> wrote >> Joep wrote >>> Rod Speed <rod.speed.aaa(a)gmail.com> wrote >>>> Joep wrote >>>>> Rod Speed <rod.speed.aaa(a)gmail.com> wrote >>>>>> Joep wrote >>>>>>> Ato_Zee <ato_zee(a)hotmail.com> wrote >>>>>>>> Joep <available(a)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. |