Do disk defraggers check file systems first?
in [Storage]
|
From: Joep on 9 Oct 2009 05:56 "Ato_Zee" <ato_zee(a)hotmail.com> schreef in bericht news:JEYym.14389$Xz6.8172(a)newsfe18.ams2... > > On 7-Oct-2009, "Joep" <available(a)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.
From: Ato_Zee on 9 Oct 2009 10:20 On 9-Oct-2009, "Joep" <available(a)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.
From: Rod Speed on 9 Oct 2009 21:01 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. >> 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.
From: Joep on 10 Oct 2009 07:56 "Ato_Zee" <ato_zee(a)hotmail.com> schreef in bericht news:oEHzm.15881$Tt7.4506(a)newsfe20.ams2... > > On 9-Oct-2009, "Joep" <available(a)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.
From: Joep on 10 Oct 2009 08:00
"Rod Speed" <rod.speed.aaa(a)gmail.com> schreef in bericht news:7ja4mmF34o0hlU1(a)mid.individual.net... > 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. > >>> 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? |