Do disk defraggers check file systems first?
in [Storage]
|
From: Joep on 12 Oct 2009 11:29 "Ato_Zee" <ato_zee(a)hotmail.com> schreef in bericht news:REGAm.15884$xF1.8490(a)newsfe10.ams2... > > On 12-Oct-2009, "Joep" <available(a)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.
From: Joep on 12 Oct 2009 11:32 "Rod Speed" <rod.speed.aaa(a)gmail.com> schreef in bericht news:7jfdhhF352vjgU1(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 >>>>>> 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. 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. > >
From: Rod Speed on 12 Oct 2009 15:04 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 >>>>> 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. > No actually it isn't, just try it for yourself. 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.
From: Rod Speed on 12 Oct 2009 15:15 Joep wrote > Ato_Zee <ato_zee(a)hotmail.com> wrote >> Joep <available(a)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. > 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.
From: Rod Speed on 12 Oct 2009 15:18
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 >>>>>>> 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. > 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. |