Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 26 reacties
Bron: Raxco, submitter: olafheij

PerfectDisk logo (75 pix) Raxco Software heeft service pack 2 voor versie 13.0 van zijn defragmenteerprogramma PerfectDisk uitgebracht. Dit programma reorganiseert de locatie en volgorde van de bestanden op de harde schijf, zodat deze sneller te benaderen zijn. Dit resulteert in het sneller starten van programma's en het sneller booten van de pc. PerfectDisk is geschikt voor Windows XP en hoger, voor zowel de 32bit- als de 64bit-varianten. Een evaluatieversie kan op deze pagina worden gedownload. Prijzen beginnen bij dertig dollar voor een enkele thuislicentie. Sinds versie 12.5 zijn de volgende veranderingen en verbeteringen aangebracht:

What's new in PerfectDisk 13 Service Pack 2 (Build 821)
  • Improvements made in StealthPatrol "idle" processing.
  • Selected File defrag on mount point issue fixed.
  • PerfectDisk Exchange fails to create backup file issue fixed.
  • Scheduled task runs twice in a row issue fixed.
  • Support for defragmenting ReFS drives added.
  • Support for defragmenting CSVFS drives added (2012/2012 R2).
  • Boot time defrag options missing in Drive Perferences for mount points and unmounted drives issue fixed.
  • Pagefile stats not included in Analyze and Defrag stats fixed.
What's new in PerfectDisk 13 Service Pack 1 (Build 783)
  • Expired PerfectDisk 12.5 evaluation license prevents 'Apply License' on installation of PerfectDisk 13 issue fixed.
  • Boot time defrag logging issue fixed.
  • Product registration failure on Windows 8.1 with high UAC issue fixed.
  • Check for Update doesn't find available update issue fixed.
What's new in PerfectDisk 13 (Build 776)
  • Fixed an issue on Windows 8.1 systems where Windows wouldn't boot after requesting a boot time defrag:
    • Windows 8.1 systems only
    • PD12.5 installed
    • Hotfix applied to allow PD12.5 to run on Windows 8.1
    • Upgraded using PD13 Build 770 provided to pre-release customers
    • Boot time defrag requested in PD13
  • Fixed issue where OptiWrite settings were not being correctly migrated on upgrade from PD12.x to PD1

PerfectDisk 13 screenshot

Moderatie-faq Wijzig weergave

Reacties (26)

Ik weet het niet met die defragtools. Gebruik zelf de bij Windows meegeleverde defrag-tool en heb er geen omkijken naar.

Toen ik voor de lol eens enkele andere tools liet 'kijken' (dus niet laten defragmenteren) hoeveel fragmentatie er zou zijn op mijn 4 HDD's, waren de resultaten wel zeer uiteenlopend. Het ging om OO Defrag, Perfect Disk, Defraggler, UltraDefrag, en Auslogics Disk Defrag.

De Windows defrag-tool gaf 0% - 2% fragmentatie aan terwijl sommige andere uitschieters aangaven van wel 60%(!).

Natuurlijk zal ieder programma zijn eigen methodes hebben om fragmentatie te berekenen, maar zo wordt je er natuurlijk geen drol wijzer van. Als je met het ene programma defragmenteerd zegt het andere programma juist weer dat het een bende is en je (dus weer) moet defragmenteren.

[Reactie gewijzigd door ironx op 19 augustus 2014 15:05]

Hangt er ook vanaf waar en hoe je de files gegroepeerd wil hebben. (einde schijf / begin schijf / op alfabet noem maar op)

Zelf had ik ooit een progje die zette de files gedefragmenteerd per directory bij elkaar.
Dat werkte super, als je een programma moest opstarten die veel in zijn eigen directory rommelt stonden die files al lekker bij elkaar.

Daardoor kan soms defraggen bij een harddisk tot perfomance degradatie lijden als je dat soort files wel defragt maar dan over de hele schijf verplaatst: Beter gefragmenteerd bij elkaar dan gedefragmenteerd uit elkaar in dat geval.
Interessant. Kan je dit ook repliceren?
Als een bestand wordt geÔndexeerd volgens de FAT zou het volgens mij de bedoeling zijn dat het in zo weinig mogelijk adressen wordt opgeslagen, en in het geval van een traditionele harde schijf nog in volgorde ook :P
Ik gebruik het nog wel om b.v. mijn gewone schijven te defragmenteren, ook mijn wat oudere systemen welke nog geen SSD hebben maken nog gebruik van dit programma. Het doet zijn werk goed.
Heb je dit zelf getest, een vergelijking met andere progjes gemaakt.

Hier nog wat testen om door te lezen:
http://www.gamingpcbuilde...isk-defragmenters-tested/
http://www.hofmannc.de/en...nter-test/benchmarks.html
http://www.overclock.net/...hich-defragmenter-is-best

[Reactie gewijzigd door Toine1 op 19 augustus 2014 13:09]

Thanks: Conclusie: Defragmentatie programma's zijn weggegooid geld.

Installeer een SSD, dat zet zooden aan de dijk!
Volgens Raxco kun je deze tool prima gebruiken met een SSD. De vraag is alleen: heeft het zin, en heeft iemand hiermee i.c.m. een SSD ervaring?

[Reactie gewijzigd door zoef40 op 19 augustus 2014 09:47]

Defragmenteren is totaal nutteloos op een SSD.
Dat is dus nog maar de vraag,

Als een schijf met kleine bestanden super gefragmenteerd is, heb je dus een fat table van hier tot tokio en terug.
Dan hangt het dus van het o.s. en het opslagmedium af of daar geen vertraging onstaat.
Is dat wel het geval dan heeft defragmentatie wel zin maar dan om de fat table te reduceren.

voor fat 32 bijv. geldt : het maximum aantal clusters op een FAT32-volume is 268,435,445 en er is een maximum van 32 KB per cluster, samen met de benodigde ruimte voor de bestandstoewijzingstabel (FAT).

Bij mij is er in ieder geval een ssd merkbaar er sneller van geworden. Of dat door de "butt-dyno" komt weet ik echter niet....

Zo heb ik ook wel eens een vreselijk trage first gen ssd sneller gekregen door windows compressie in te schakelen op de ssd.... minder schrijfacties en meer ruimte , werkte toen... nu missch. niet meer...

[Reactie gewijzigd door hatex op 19 augustus 2014 10:20]

Als een schijf met kleine bestanden super gefragmenteerd is, heb je dus een fat table van hier tot tokio en terug.
Dat is volslagen onzin. Een FA Table bevat alleen een soort linked lists van de clusters die ieder bestand gebruikt, en dat neemt altijd exact dezelfde ruimte in, ongeacht de fragmentatie van de bestanden.
Eventuele vertraging door fragmentatie zit hem ook totaal niet in de FAT, maar in het random heen en weer moeten springen (verspreid over de disk) bij het lezen of schrijven van gefragmenteerde bestanden.

Bij een SSD is geen sprake van een lees-/schrijfkop of iets anders dat fysiek heen en weer moet springen, en dus boeit fragmentatie daar niet.

[Reactie gewijzigd door kumquat op 19 augustus 2014 11:42]

Ik lees t anders :
Die linked list IS dus onderdeel van je FAT table.
Als een file over 40 plaatsen verspreid staat, staan er dus 40 vermeldingen in je fat table ipv 1. Het lijkt me niet dat die ruimte op voorhand al gereserveerd is.
Theoretisch zou een fat32 table zelfs 1 gigabyte groot kunnen worden.
Ik weet niet hoe jij daarover denkt , maar die wil ik toch niet graag continu in mij o.s. gecached hebben....

De Fat tables zijn dus niet altijd even groot zoals jij stelt en ook die raken gefragmenteerd.

bron1:
MFT Reservation and Fragmentation :
MFT contains frequently used system files and indexes, so performance of MFT affects a lot to the entire volume performance.

By default NTFS reserves zone, 12.5% of volume size for MFT and does not allow writing there any user's data, which lets MFT to grow. However, when, for example, a lot of files are placed to the drive, MFT can grow beyond the reserved zone and becomes fragmented.

Another reason is when you delete file, NTFS does not always use its space in MFT to store new one, it just marks MFT entry as deleted and allocates new entry for the new file. It provides some performance and recovery benefits, however it forces MFT to be fragmented.

bron2:
Still worse, if we increase the size of the FAT32 volume from 2 GiB in size to 8 GiB, the size of the FAT increases from around 2 MiB to a rather hefty 8 MiB. The significance of this is not the fact that the FAT32 volume will have to waste several megabytes of space on the disk to hold the FAT. The real problem is that the FAT is referred to a lot during normal use of the disk, since it holds all the cluster pointers for every file in the volume. Having the FAT greatly increase in size can negatively impact system speed.

Virtually every system employs disk caching to hold in memory disk structures that are frequently accessed, like the FAT. The disk cache employs part of main memory to hold disk information that is needed regularly, to save having to read it from the disk each time (which is very slow compared to the memory). When the FAT is small, like the 128 kiB FAT used for FAT16, the entire FAT can be held in memory easily, and any time we need to look up something in the FAT it is there at our "fingertips". When the table increases in size to 8 MiB for example, the system is forced to choose between two unsavory alternatives: either use up a large amount of memory to hold the FAT, or don't hold it in memory.

For this reason, it is important to limit the size of the file allocation table to a reasonably-sized number. In fact, in most cases it is a matter of finding a balance between cluster size and FAT size. A good illustration of this is the cluster size selections made by FAT32 itself. Since FAT32 can handle around 268 million maximum clusters, the 4 kiB cluster size is technically able to support a disk volume 1 TiB (1,024 GiB) in size. The little problem here is that the FAT size would be astronomical--over 1 GB! (268 million times 4 bytes per entry).

For this reason, FAT32 only uses 4 kiB clusters for volumes up to 8 GiB in size, and then quickly "upshifts" to larger clusters.
Nope, als een file 40 clusters aan diskspace inneemt beslaat hij per definitie 40 entries in de FAT. Ongeacht of die 40 clusters allemaal netjes lineair achter elkaar liggen, of kris kras verspreid over de hele disk.

FA Tables (of FATs, niet FAT Tables, de T staat al voor table) zijn uiteraard niet altijd overal even groot, maar op een bepaalde disk, eenmaal geformatteerd, heeft de FAT een vaste grootte die alleen afhangt van de diskgrootte en gekozen clustergrootte. Niet van het aantal bestanden, noch de grootte of fragmentatie van die bestanden. Die ruimte is inderdaad al van te voren gereserveerd (gebeurt bij het formatteren).

Zo'n FAT wordt nooit 1gig groot, voor grotere volumes worden standaard ook grotere clusters gekozen zodat het aantal entries in de FAT beperkt blijft. Dat zorgt wel voor meer verspilde ruimte aan het eind van elke file (resterende deel van laatste cluster aka 'slack' wordt niet gebruikt) maar dat heeft niets met fragmentatie van doen.

Een MFT is iets van NTFS, niet van FAT. En NTFS en FAT hebben niets met elkaar te maken, zijn twee totaal verschillende bestandssystemen.
Het is niet mijn bedoeling de verschillende implementaties van File Allocation Tabels (mft / fats hoe je ze ook wil noemen) te benoemen. Ik snap dat er is verschil tussen FAT32 en NTFS en andere DFS'sen.
Daar gaat t niet specifiek om.

Volgens NTFS.COM kan een Master File Table wel buiten zijn vooraf gereserveerde grootte groeien en dus gefragmenteerd raken.
quote "However, when, for example, a lot of files are placed to the drive, MFT can grow beyond the reserved zone and becomes fragmented."

Maar goed vraag is, heeft het zin een SSD te defraggen, ik denk dus van wel o.a. vanwege het bovenstaande en jij van niet. No Problem.
Als het klopt wat er staat kan het wel degelijk zinvol zijn.

Dus door vrije blokken te consolideren (wat dus niet defragmenteren is) voor statische data, zoals je OS-binaries ervoor zorgen dat TRIM efficiŽnter loopt, en wear-leveling beter werkt, zou het dus zelfs de levensduur van je apparaat vergroten.
Defragmenteren heeft altijd zin, het onderliggende medium op zich verandert daar niks aan. De vraag is echter of het de extra slijtage waard is? Mijn mening is van wel: random 4k performance van een SSD is een trieste 30-40 MBps, in schril contrast met de 500+ MBps bij een sequential read. Defragmenteren heeft dus duidelijk zin, maar je voelt minder snel de negatieve gevolgen van fragmentatie bij een SSD.

Ikzelf laat mijn schijf op SSD optimize staan, maar maandelijks doe ik een SMARTPlacement, zoals bij een klassieke schijf. De performance van mijn schijf gaat dan van 90% naar 100% volgens PerfectDisk, en blijft niet staan op 90% wanneer ik enkel SSD optimize doe. SSD optimize komt enkel de schrijfsnelheid ten goede, niet de leessnelheid welk bij een OS disk toch ook belangrijk is. Daarom overweeg ik zelf om standaard SMARTPlacement in te schakelen, welke dan ongeveer om de 4 dagen gebeurt. I.c.m. OptiWrite moet er daarna bijna nooit meer gedefragmenteerd worden omdat realtime fragmentatie vermeden wordt d.m.v. redirects door PerfectDisk.
ik heb het optimizen eens getest op mijn crucial m4 en was niet onder de indruk. ik denk dat het vooral bedoeld is voor systemen waar geen TRIM draait door hard of software beperking.
Volgens mij is een optimize ook gewoon een handmatige trim actie. Het gratis Defraggler bied trouwens die optie ook.
Dit programma gebruikte ik vroeger altijd. Maar nu met SSD mogen we het niet meer gebruiken.
Iemand ervaring met dit programma?
Ziet er goed uit.
Ik gebruik tegenwoordig vaak Defraggler, die is nog gratis ook.
Moderne SSD's kunnen tegenwoordig zoveel schrijfacties per dag aan, dat ik niet denk dat het een gevaar vormt voor de levensduur. Hoe lang doe je immers met een disk (SSD)? 3 jaar?
Of het zin heeft is wat anders, dat weet ik dus niet... lijkt me niet eigenlijk.
Mijn SSD zit er al 4 jaar in en ben voorlopig ook nog niet van plan deze te gaan vervangen.

Windows 7 laadt in minder dan 10 seconden en BF4 mutiplayer nog steeds bij de eersten die geladen zijn.

Niet iedereen heeft behoefte aan een nieuwe lease auto terwijl de 'oude' het nog prima doet ;)
Het is bij SSD's meer het geval dat als je deze 3 of 4 jaar geleden gekocht hebt, deze hooguit 64GB of 128GB is en je inmiddels wat groters wilt ;)
Tevens is een SSD van 3-4 jaar oud substantieel trager (minder snel) dan een moderne. Ik gebruik nog een Samsung 830, maar als je deze naast een 840 EVO legt dan draait die laatste er rondjes omheen en kan ook nog veel meer bewerkingen aan voordat deze "slijt".
In oudere systemen maakt dit niks uit natuurlijk; op werk hebben we nieuwe snelle SSD's zitten in 5+ jaar oude laptops met SATA 3G...
Het is dus niet zozeer behoefte aan steeds het nieuwste, maar als je je pc vaak vernieuwt wil je ook snelle SSD's en vooral groter, omdat de prijs van een 500GB SSD nu hetzelfde is als 4 jaar geleden voor een 128GB.
En toch wordt nog steeds aangeraden om voor data (lees je gigantische Blue-Ray bestanden) een extra schijf te gebruiken. Access-times doen er niet echt heel veel toe als je af en toe defragmenteert. Dat het loont om je OS en de programma's die je dagelijks gebruikt op de SSD te zetten is overduidelijk. Voor sommige games ook een aanrader. Of een loading-screen nou een of twee seconden duurt, is niet heel relevant. SSD's bieden het verschil tussen 30 seconden en 1 seconde, en dat ga je wel voelen. Allemaal mooi en wel dat het goedkoper en sneller wordt, maar het verschil tussen 1st gen SSD's en de laatste nieuwe hype maken het upgraden niet per sť nodig.

Voor de mensen die wel onder een steen hebben gelegen sinds SSD's betaalbaar zijn geworden, is een SSD een gigantische upgrade.
Alhoewel BF4 wel eens grondig ge-de-fragmenteerd mag worden ;-)
Shareware ??

Laat maar, moet ff de betekenis van shareware beter lezen |:(

[Reactie gewijzigd door SpiriTNL op 19 augustus 2014 09:51]

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True