Guardian Angel schreef op donderdag 03 augustus 2006 @ 21:43:
[...]
Tja, Diskkeeper is notabene de maker van het defragmentatieprogramma in Windows. Het enige verschil is dat het sneller werkt en voor het opstarten van Windows de MFT tabellen etc kan defragmenteren.
Het voordeel van al die programma's is voor zover ik kon vinden twijfelachtig. Even zo goed is om voor een installatie de standaard Windows defrag te gebruiken, dan staat ook alles bij elkaar.
De snelheidswinst van lezen van of schrijven naar schijf is te verwaarlozen en zeker niet de kosten van een extra programma waard.
Eensch is
Defragmentation APIs. Since the release of Windows NT 4.0, the NTFS file system has exposed APIs that allow a user-mode application to query the allocated ranges of files on disk, and optimize file arrangements in order to defragment (or carefully fragment) files in order to minimize seeks while processing file I/O. In Windows 2000, these APIs have a number of limitations; for example, they do not function on the master file table (MFT), the PageFile, or NTFS attributes. The feature set in Windows XP changes the behavior on NTFS as follows:
• The defragmentation APIs no longer defragment data by using the system cache. This means Encrypted files no longer need to be opened with read access.
• NTFS now defragments at the cluster boundary for non-compressed files. In Windows 2000, this was limited to the page granularity for non-compressed files.
• NTFS now defragments the MFT. This was not allowed in Windows 2000. This is through the regular code path, so there is no limit to how much at once can be moved, and any part of it can be moved other than the first 0x10 clusters. If there is no available space in the MFT to describe the change, then it will be rejected. The API can move an MFT segment even if a file with its File Entry in that section is currently open.
• NTFS now defragements for cluster sizes greater than 4K. NTFS now defragments Reparse points, bitmaps, and attribute_lists. These can now be opened for file read attributes and synchronize. The files are named using the regular syntax (file:name:type); for example:
foo:$i30:$INDEX_ALLOCATION foo::$DATA
foo::$REPARSE_POINT
foo::$ATTRIBUTE_LIST
• NTFS's QueryBitmap FSCTL now returns results on a byte boundary rather than page boundary.
• NTFS now defragments all parts of a stream, up to and including the allocation size. In Windows 2000, it was not possible to defragment the file tail between valid data length (VDL) and end of file (EOF).
• You can now defrag into or out of the MFT Zone. The MFT Zone is now just an NTFS-internal hint for the NTFS allocation engine.
• To defragment a file, the Win32 open mode needs only have FILE_READ_ATTRIBUTES | SYNCHRONIZE.
• It is possible to Pin an NTFS file so that it may not be defragged using FSCTL_MOVE_FILE. This is done by calling FSCTL_MARK_HANDLE and passing MARK_HANDLE_PROTECT_CLUSTERS as an argument. This stays in effect until the handle is closed.
Anoniem: 58485 schreef op donderdag 03 augustus 2006 @ 18:14:
[...]
Dat is dus niet zo
Als je windows defragmenteer vergelijkt met diskeerper, doet de windows variant niet meer dan domweg naast elkaar zetten, terwijl er bij Diskeeper bijv een patroon is van bestanden die vaak worden geaccessed, die worden ook namelijk op het beginpunt van de partitie gezet omdat daar de schijf ook het snelst is, de koppen hoeven minder lang te zoeken.
Dat doet de standaard defrag dus ook :
Prefetch
All versions of Windows except real-mode Windows 3x are demand-paged operating systems, where file data and code is faulted into memory from disk as an application attempts to access it. Data and code is faulted in page-granular chunks where a page's size is dictated by the CPU's memory management hardware. A page is 4KB on the x86. Prefetching is the process of bringing data and code pages into memory from disk before it's demanded.
In order to know what it should prefetch, the Windows XP Cache Manager monitors the page faults, both those that require that data be read from disk (hard faults) and those that simply require that data already in memory be added to a process's working set (soft faults), that occur during the boot process and application startup. By default it traces through the first two minutes of the boot process, 60 seconds following the time when all Win32 services have finished initializing, or 30 seconds following the start of the user's shell (typically Microsoft Internet Explorer), whichever of these three events occurs first. The Cache Manager also monitors the first 10 seconds of application startup. After collecting a trace that's organized into faults taken on the NTFS Master File Table (MFT) metadata file (if the application accesses files or directories on NTFS volumes), the files referenced, and the directories referenced, it notifies the prefetch component of the Task Scheduler by signaling a named event object.
The Task Scheduler then performs a call to the internal NtQuerySystemInformation system call requesting the trace data. After performing post-processing on the trace data, the Task Scheduler writes it out to a file in the \Windows\Prefetch folder. The file's name is the name of the application to which the trace applies followed by a dash and the hexadecimal representation of a hash of the file's path. The file has a .pf extension, so an example would be NOTEPAD.EXE-AF43252301.PF.
An exception to the file name rule is the file that stores the boot's trace, which is always named NTOSBOOT-B00DFAAD.PF (a convolution of the hexadecimal-compatible word BAADF00D, which programmers often use to represent uninitialized data). Only after the Cache Manager has finished the boot trace (the time of which was defined earlier) does it collect page fault information for specific applications.
When the system boots or an application starts, the Cache Manager is called to give it an opportunity to perform prefetching. The Cache Manager looks in the prefetch directory to see if a trace file exists for the prefetch scenario in question. If it does, the Cache Manager calls NTFS to prefetch any MFT metadata file references, reads in the contents of each of the directories referenced, and finally opens each file referenced. It then calls the Memory Manager to read in any data and code specified in the trace that's not already in memory. The Memory Manager initiates all of the reads asynchronously and then waits for them to complete before letting an application's startup continue.
How does this scheme provide a performance benefit? The answer lies in the fact that during typical system boot or application startup, the order of faults is such that some pages are brought in from one part of a file, then from another part of the same file, then pages are read from a different file, then perhaps from a directory, and so on. This jumping around results in moving the heads around on the disk. Microsoft has learned through analysis that this slows boot and application startup times. By prefetching data from a file or directory all at once before accessing another one, this scattered seeking for data on the disk is greatly reduced or eliminated, thus improving the overall time for system and application startup.
To minimize seeking even further, every three days or so, during system idle periods, the Task Scheduler organizes a list of files and directories in the order that they are referenced during a boot or application start, and stores the list in a file named \Windows\Prefech\Layout.ini. Figure 1 shows the contents of a prefetch directory, highlighting the layout file. Then it launches the system defragmenter with a command-line option that tells the defragmenter to defragment based on the contents of the file instead of performing a full defrag. The defragmenter finds a contiguous area on each volume large enough to hold all the listed files and directories that reside on that volume and then moves them in their entirety into that area so that they are stored one after the other. Thus, future prefetch operations will even be more efficient because all the data to be read in is now stored physically on the disk in the order it will be read. Since the number of files defragmented for prefetching is usually only in the hundreds, this defragmentation is much faster than full defragmentations.
alles staat gewoon nog over de hele schijf verspreid, en echt effectief is het niet.
:strip_icc():strip_exif()/u/15283/pinkypimp.jpg?f=community)
/u/7737/dsotm.png?f=community)
:strip_icc():strip_exif()/u/13964/crop66d0a93a33207_cropped.jpg?f=community)
:strip_icc():strip_exif()/u/180657/texacoiq2.jpg?f=community)
:strip_exif()/u/54199/crop5fac3f2ee1eff.gif?f=community)
:strip_icc():strip_exif()/u/50793/thumb-exorcist.jpg?f=community)
:strip_exif()/u/11775/SoulTaker.gif?f=community)
