Defragmentatie

Pagina: 1
Acties:
  • 285 views sinds 30-01-2008
  • Reageer

Acties:
  • 0 Henk 'm!

Anoniem: 146790

Topicstarter
Ik heb nu al een paar dagen Windows erop staan. Voordat ik weer begin met het hele systeem in orde maken, wil ik toch eerst antwoord op mijn vraag.
Het defragmenteren van mijn HDD ziet er ontzettend lomp uit.
Ik defragmenteer met Diskeeper.

* Hij begint met defragmenteren, je kunt zien dat hij files verplaatst naar een ander gedeelte, maar op het laatste als hij klaar is ziet het er zo uit :

http://members.home.nl/ramon-hesseling/Diskeeper.JPG

Dit lijkt me nou niet echt het beeld van een gedefragmenteerde harde schijf :? alles staat gewoon nog over de hele schijf verspreid, en echt effectief is het niet.

Acties:
  • 0 Henk 'm!

  • RaZ
  • Registratie: November 2000
  • Niet online

RaZ

Funky Cold Medina

Niets mis mee zo te zien.

Het is niet meer zoals vroeger zoals je Norton Speedisk had (DOS tijdperk), dat de bestanden met +r en +s naar voren werden verplaatst.

Ik zou me er niet druk om maken.

[ Voor 3% gewijzigd door RaZ op 03-08-2006 16:56 ]

Ey!! Macarena \o/


Acties:
  • 0 Henk 'm!

  • frickY
  • Registratie: Juli 2001
  • Laatst online: 09-06 21:17
Liever defragmenteren in veilige modus ;)
Dan draaien er minder programma's en services, en kan er meer verplaatst worden.
For the time being ook even virtueel geheugen uitschakelen.

Acties:
  • 0 Henk 'm!

Anoniem: 146790

Topicstarter
frickY schreef op donderdag 03 augustus 2006 @ 17:04:
Liever defragmenteren in veilige modus ;)
Dan draaien er minder programma's en services, en kan er meer verplaatst worden.
For the time being ook even virtueel geheugen uitschakelen.
In veilige modus defragmenteren heb ik nog nooit gedaan. Het is een tijd geleden ook fatsoenlijk gelukt, alles stond kaarsrecht naast
Het Virtueel Geheugen is uitgeschakeld, maar blijkbaar is dat groene ergens anders voor?
Niets mis mee zo te zien.

Het is niet meer zoals vroeger zoals je Norton Speedisk had (DOS tijdperk), dat de bestanden met +r en +s naar voren werden verplaatst.

Ik zou me er niet druk om maken.
Niets mis mee? Ik heb het eerlijk gezegd nog nooit zo gezien.
En vroeger, was ik er waarschijnlijk niet eens :P

Acties:
  • 0 Henk 'm!

  • Arnaud
  • Registratie: Mei 2000
  • Laatst online: 08-06 08:10
Dat ziet er inderdaad vaag uit. Vooral "system files" is raar als je inderdaad je pagefile uit hebt staan. Vraag het eens aan de makers van het programma (http://www.diskeeper.com/support/support.asp)

Acties:
  • 0 Henk 'm!

Anoniem: 58485

Die system files kunnen ook System restore zijn mits de ts dat aan heeft staan.

verders niet zo druk maken over dat je bestanden gescatterd worden over de harde schijf, in feite komen nieuwe bestanden dan recht achter elkaar op het punt waar het gedefragmenteert is , ook niet handig dus.

Acties:
  • 0 Henk 'm!

  • Arnaud
  • Registratie: Mei 2000
  • Laatst online: 08-06 08:10
Wat is de output van "defrag X: -a -v"?

En doe eens een "defrag X: -f -v" als de output "You should defragment this volume." was.

Acties:
  • 0 Henk 'm!

  • Guardian Angel
  • Registratie: Juni 2000
  • Niet online

Guardian Angel

Bejaard en langharig tuig

Er zijn verschillende methodes van defragmenteren. Waarschijnlijk heb je een optie gekozen waarbij alleen de bestanden worden gedefragmenteerd en niet de lege ruimtes worden benut.

Overigens is het standaard in Windows aanwezige programma even goed en is het zonde om geld uit te geven aan dit soort programma's.

ARME AOW’er


Acties:
  • 0 Henk 'm!

Anoniem: 58485

Guardian Angel schreef op donderdag 03 augustus 2006 @ 17:51:


Overigens is het standaard in Windows aanwezige programma even goed en is het zonde om geld uit te geven aan dit soort programma's.
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.

Er was ooit een test met Windows98 in die bladen en daarbij vergeleken ze een handvol programma's en natuurlijk als eenerlaatste kwam de windows defragmenter daar als slechtste uit. Nu bedoel ik niet dat dat ook maar gelijk voor XP geldt, maar een alternatief zoals Diskeeper is gewoon beter.

Zelf werk ik er ondertussen jaren mee.
BalusC schreef op donderdag 03 augustus 2006 @ 18:14:
Overigens, als je NTFS hebt, dan is defragmenteren nutteloos. Dat komt omdat NTFS uit zichzelf fragmenteert, echter het maakt er slim genoeg gebruik van :) Gewoon niet moeilijk over doen en lekker zo laten.
Dat is wel zo :) maar fragmentatie treedt toch hoe dan ook op als je niet fragmenteert, en je schijf wordt echt langzamer. Mooi voorbeeld is een schijf die je alleen gebruikt voor downloaden, flinke files, 50mb per stuk etc,veel quickparren / extracten enzo,, die wordt na verloop van tijd echt toch te langzaam hoor.

[ Voor 24% gewijzigd door Anoniem: 58485 op 03-08-2006 18:17 ]


Acties:
  • 0 Henk 'm!

  • BalusC
  • Registratie: Oktober 2000
  • Niet online

BalusC

Carpe diem

Overigens, als je NTFS hebt, dan is defragmenteren nutteloos. Dat komt omdat NTFS uit zichzelf fragmenteert, echter het maakt er slim genoeg gebruik van :) Gewoon niet moeilijk over doen en lekker zo laten.

[ Voor 14% gewijzigd door BalusC op 03-08-2006 18:15 ]


Acties:
  • 0 Henk 'm!

  • Avalaxy
  • Registratie: Juni 2006
  • Nu online
BalusC schreef op donderdag 03 augustus 2006 @ 18:14:
Overigens, als je NTFS hebt, dan is defragmenteren nutteloos. Dat komt omdat NTFS uit zichzelf fragmenteert, echter het maakt er slim genoeg gebruik van :) Gewoon niet moeilijk over doen en lekker zo laten.
bs, ik heb ook NTFS, en als mijn schijven gefragmenteerd raken defragmenteer ik, en dan merk ik wel degelijk een grote performance boost. Mijn D schijf fragmenteerd zelf helemaal niet uit zichzelf dus die hoef ik nooit te defraggen :X

het heeft gewoon te maken met hoeveel shit je erop/eraf zet etc.

Acties:
  • 0 Henk 'm!

  • BalusC
  • Registratie: Oktober 2000
  • Niet online

BalusC

Carpe diem

een grote performance boost
Laat eens cijfers zien :)

Acties:
  • 0 Henk 'm!

Anoniem: 146790

Topicstarter
Arnaud schreef op donderdag 03 augustus 2006 @ 17:19:
Dat ziet er inderdaad vaag uit. Vooral "system files" is raar als je inderdaad je pagefile uit hebt staan. Vraag het eens aan de makers van het programma (http://www.diskeeper.com/support/support.asp)
Precies, dat dacht ik dus ook.
Die system files kunnen ook System restore zijn mits de ts dat aan heeft staan.

verders niet zo druk maken over dat je bestanden gescatterd worden over de harde schijf, in feite komen nieuwe bestanden dan recht achter elkaar op het punt waar het gedefragmenteert is , ook niet handig dus.
System restore staat uit, er stond eerst nog wel een file "hibernate.sys" maar dat was de slaapstand, die heb ik nu ook uit staan. En de nieuwe bestanden komen wel ergens achter, maar als bestandje 1 op het middelste van de schijf word gezet, en dan verder word geschreven aan de buitenkant, is het niet effectief lijkt me?
Wat is de output van "defrag X: -a -v"?

En doe eens een "defrag X: -f -v" als de output "You should defragment this volume." was.
Die snap ik niet :) Uitleg?
Er zijn verschillende methodes van defragmenteren. Waarschijnlijk heb je een optie gekozen waarbij alleen de bestanden worden gedefragmenteerd en niet de lege ruimtes worden benut.

Overigens is het standaard in Windows aanwezige programma even goed en is het zonde om geld uit te geven aan dit soort programma's.
De methodes zal ik eens voor de zekerheid nakijken, en het standaard aanwezige programma is zoals iemand anders al zei niet zo goed als Diskeeper, al gaat het al om de opties die je kunt instellen (Zoals in deze post iets naar boven staat). Verder heb ik er ook geen geld aan uitgegeven 'natuurlijk'.

Acties:
  • 0 Henk 'm!

Anoniem: 146790

Topicstarter
Job Report
Volume (C:):

Recommendations
--------------------------------------------------------------------------
Findings on C:

Diskeeper has completed a defragmentation run on this
volume and there remain 0 fragmented files and/or
directories and 0 excess fragments. (There were 73 excess
fragments before the defragmentation run, and now there are
100% fewer.)

The average number of fragments per file is 1,00.

Congratulations! There are no excess file or directory
fragments on this volume. The files on this volume are as
defragmented as possible. Still, you should use the Smart
Scheduling option in Diskeeper to automatically keep
fragmentation at a low level. Click Set It and Forget It in
the Quick Launch pane to specify a Smart Schedule.
1. Due
to the high memory usage it is recommended that you run
Frag Shield to expand your paging file.


Health
--------------------------------------------------------------------------
Warning!

The overall health of volume C: is degraded

The overall health is at "Warning" level for the following
reasons:

1. The peak memory usage since the last reboot was 72
percent of the total available memory, which indicates it
is likely the paging file will become fragmented.


Access Time
--------------------------------------------------------------------------
Time to read all files on volume C

Current read time: 203 milliseconds

Optimum read time: 203 milliseconds

0% improvement


Time to read fragmented files on volume C

Current read time: 86 seconds

Optimum read time: 86 seconds

0% improvement


Statistics
--------------------------------------------------------------------------

Volume Files
Volume size = 26.317 MB
Cluster size = 4 KB
Used space = 2.270 MB
Free space = 24.046 MB
Percent free space = 91 %
Defragmentation method =

Fragmentation percentage
Volume fragmentation = 0 %
Data fragmentation = 0 %

Directory fragmentation
Total directories = 1.367
Fragmented directories = 0
Excess directory fragments = 0

File fragmentation
Total files = 13.283
Average file size = 177 KB
Total fragmented files = 0
Total excess fragments = 0
Average fragments per file = 1.00
Files with performance loss = 0

Paging file fragmentation
Paging/Swap file size = 0 bytes
Total fragments = 0

Master File Table (MFT) fragmentation
Total MFT size = 44.155 KB
MFT records In Use = 14.690
Percent MFT in use = 33 %
Total MFT fragments = 0


Most Fragmented Files
--------------------------------------------------------------------------
Fragments File size Most fragmented files
None

Acties:
  • 0 Henk 'm!

  • ParkOverall
  • Registratie: Maart 2004
  • Laatst online: 09:19
Gebruik: O&O Defrag. Best getest door c't (D). Ook PerfectDisk was goed, de rest duidelijk minder (tot slecht). Verder vond men dat je weinig (paar procent) prestatie-winst kunt verwachten.

Acties:
  • 0 Henk 'm!

  • RemcoDelft
  • Registratie: April 2002
  • Laatst online: 03-05 10:30
Waarom zou je na enkele dagen willen defragmenteren? Dat heeft net zo veel nut als na enkele dagen je toetsenbord stofzuigen...

Acties:
  • 0 Henk 'm!

Anoniem: 58485

RemcoDelft schreef op donderdag 03 augustus 2006 @ 20:05:
Waarom zou je na enkele dagen willen defragmenteren? Dat heeft net zo veel nut als na enkele dagen je toetsenbord stofzuigen...
Of het zinvol is na een paar dagen hangt af van je gebruik met de harde schijf. Fragmentatie treedt op wanneer er een programma geinstalleerd is en later verwijder is, er komt dan in feite een "kale" plek te staan op je harde schijf. doe je nauwelijks wat met je schijf, hoef je ook niet te defragmenteren.

nou ik heb ondertussen een test gedaan met HDtach op m'n downloadschijf die ondertussen wel aanzienlijk trager is geworden (gevoelsmatig) en ben 'm nu nog steeds aan het defragmenteren. Als het klaar is zal ik een stapel pics posten waar we denk ik allemaal stuk wijzer van worden. :)

Acties:
  • 0 Henk 'm!

  • Guardian Angel
  • Registratie: Juni 2000
  • Niet online

Guardian Angel

Bejaard en langharig tuig

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.
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.

ARME AOW’er


Acties:
  • 0 Henk 'm!

Anoniem: 58485

Guardian Angel schreef op donderdag 03 augustus 2006 @ 21:43:
[...]

De snelheidswinst van lezen van of schrijven naar schijf is te verwaarlozen en zeker niet de kosten van een extra programma waard.
Dat ben ik met je eens. :)

Nou ja iig de testen maar es gedaan... koste ruim 2.5 uur om de schijf te defragmenteren met diskeeper.

Deze test is gedaan voor de defragmentatie.
Afbeeldingslocatie: http://members.home.nl/lism.1/hdtach1.jpg
Afbeeldingslocatie: http://members.home.nl/lism.1/hdtach2.jpg

ff een screenshotje erbij van diskeeper analysys, lekker rommelig eruit :P

Afbeeldingslocatie: http://members.home.nl/lism.1/hdtach3.jpg
Afbeeldingslocatie: http://members.home.nl/lism.1/hdtach4.jpg

En hier de test na de defrag. Het maakt eigenlijk geen bal uit, mischien een miliseconde snellere accesstijden, en bij het uitpakken van files ook wat snelheidswinst, maar daar blijft het bij.

Acties:
  • 0 Henk 'm!

  • DaCoTa
  • Registratie: April 2002
  • Laatst online: 12-06 10:26
Ja, dat is ook geen nuttige test... Die susstained transfer kijkt niet eens naar het bestandssysteem. Je moet diskintensieve applicaties testen. Start een photoshop op van zo'n disk, outlook, of een spel ofzo (en dan niet mijnenveger ;)). Opstarttijd van Windows is ook een goede maatstaf. Het is ook waar ik iedere installatie van Windows mee afsluit, omdat het na installatie al een gefragmenteerde bende is.

Real life voorbeeld: het verschil tussen direct een email openen of er 10 seconden over doen omdat de Outlook .pst file in 16000 fragmenten op disk staat :) Resultaat van een jaar lang niet defragmenteren.

Of het aanmaken van een meerdere GB database op een gefragmenteerde disk en je kan al je database performance metingen uit het raam kieperen. Laat staat fatsoenlijk ontwikkelen :)

[ Voor 28% gewijzigd door DaCoTa op 04-08-2006 08:04 ]


Acties:
  • 0 Henk 'm!

  • Nielson
  • Registratie: Juni 2001
  • Laatst online: 08:54
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.

Anoniem: 10506

Door de algemene titel van dit topic stel ik deze vraag maar hier: Biedt het kopiëren van bestanden van de ene schijf naar de andere en weer terug een alternatief voor defragmentatie? Stel ik heb naast een gevulde schijf een lege schijf. Kan ik dan een gedeelte van de data defragmenteren door deze te verplaatsen naar de lege schijf en vervolgens weer terug te zetten? De gedachte hierachter is dat als er bestand voor bestand gekopieerd wordt de computer de bestanden automatisch (zij het op een ruwe manier) gedefragmenteerd op de lege schijf zet. Defragmenteren duurt vaak veel langer dan kopiëren

Voor een schijf met systeembestanden is dit natuurlijk niet echt handig, maar ik kan me voorstellen dat in andere gevallen dit een goed alternatief zou kunnen zijn voor een defragmentatieprogramma. Of zie ik nu het één en ander over het hoofd? Ook al zou je er helemaal niks aan hebben: ik vraag me toch af hoe het kopiëren van bestanden de fragmentatie beinvloedt.

  • Exorcist
  • Registratie: Maart 2002
  • Niet online

Exorcist

Uitdrijvûrrrr!

BalusC schreef op donderdag 03 augustus 2006 @ 18:14:
Overigens, als je NTFS hebt, dan is defragmenteren nutteloos. Dat komt omdat NTFS uit zichzelf fragmenteert, echter het maakt er slim genoeg gebruik van :) Gewoon niet moeilijk over doen en lekker zo laten.
Ik ben het niet met je eens, maar dat is gevoelsmatig. Nadat ik mijn schijf heb gedefragmenteert "voelt" het echt sneller aan, en ik loop lang genoeg mee om dit te merken.
Overigens, NTFS kan dan wel er "slim" mee omgaan, maar slim genoeg in de zin van koppen die niet continue heen en weer hoeven te bewegen?

  • Soultaker
  • Registratie: September 2000
  • Nu online
Klopt, dat werkt wel een beetje, maar natuurlijk alleen als je ueberhaupt grote stukken vrije ruimte hebt. Als je een partitie helemaal vol hebt staan en je haalt er een groot bestand vanaf, dan kun je 'm bij het terugkopiëren logischerwijs alleen maar naar de clusters kopiëren waar 'ie al op stond, en dan schiet je er niets mee op.

Echt defragmenteren verplaatst ook bestanden, zodat de vrije ruimte in grotere clusters terecht komt, en bestanden die nooit geschreven worden dicht achter elkaar gezet worden. Dat krijg je met heen en weer kopiëren niet voor elkaar.

Anoniem: 10506

Soultaker schreef op donderdag 31 augustus 2006 @ 17:20:
Klopt, dat werkt wel een beetje, maar natuurlijk alleen als je ueberhaupt grote stukken vrije ruimte hebt. Als je een partitie helemaal vol hebt staan en je haalt er een groot bestand vanaf, dan kun je 'm bij het terugkopiëren logischerwijs alleen maar naar de clusters kopiëren waar 'ie al op stond, en dan schiet je er niets mee op.
Ja ik ga er dus vanuit dat een groot gedeelte gekopieerd wordt. Bijvoorbeeld 10 GB van 12.5 GB op een 20GB partitie (alles behalve Windows directory en draaiende programma's)
Echt defragmenteren verplaatst ook bestanden, zodat de vrije ruimte in grotere clusters terecht komt, en bestanden die nooit geschreven worden dicht achter elkaar gezet worden. Dat krijg je met heen en weer kopiëren niet voor elkaar.
Dat klopt inderdaad. Je loopt dus kans dat de zaak vrij snel alweer fragmenteert. Verder vraag ik me af of er een verschil is met kopiëren en defragmenteren van bestanden die in dezelfde directory staan: staan deze op schijf dichter bijelkaar?

De zaak is bij mij nu behoorlijk gefragmenteerd aan het raken. Als ik eraan toekom ga ik eens kijken wat het kopiëren precies oplevert.
Pagina: 1