Software-update: PerfectDisk 13.0 build 843

Raxco Software heeft service pack 4 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. In deze release zijn de volgende veranderingen en verbeteringen aangebracht:

What’s new in PerfectDisk 13 Service Pack 4 (Build 843)

• Added the ability to detect files that are approaching the NTFS File Attribute List max size of 256KB and exclude them from defragmentation operations. Files that exceed this limit can not create additional file fragments - resulting in application or other errors. Note that this limit has nothing to do with the actual size of a file. This limit has to do with how badly fragmented the file is. If a file is badly fragmented and is approaching this limit, defragmenting the file could push it over the limit.
  For more information, please see this blog post.
• Log Viewer sorting issue fixed.
• Changes made for PerfectDisk for vSphere to work with vSphere 6.0.

Versienummer	13.0 build 843
Releasestatus	Final
Besturingssystemen	Windows 7, Windows XP, Windows Vista, Windows 8, Windows 10
Website	Raxco Software
Download	http://raxco.com/support/Updates.aspx
Bestandsgrootte	20,90MB
Licentietype	Shareware

Reacties (36)

[stijn12]

Misschien een stomme vraag maar heeft dit nog zin met een SSD?

[Nathilion]

Nee, defragmentatie heeft geen zin voor een SSD. De reden hiervoor is dat een SSD geen bewegende componenten heeft. Of data nu van sector 0 of sector 1337 moet komen, de toegangstijd is altijd even snel; ook voor een brok data dat over de hele schijf is verspreid. Dit in tegenstelling tot een traditionele harde schijf die een bewegende arm heeft om te lezen en schrijven. Hier moet dan eerst de arm voor in positie gebracht worden, en dan is het sneller als alle databrokjes netjes achter elkaar staan dan verspreid over het oppervlak van de schijf.

[miicker]

Een SSD wordt normaliter niet geformatteerd, een SSD heeft een kortere levensduur dan een HDD en kan minder vaak beschreven/gelezen worden. Tijden het defragmenteren wordt een schijf ontzettend veel keren gelezen (en volgens mij ook beschreven). Ik weet dat veel defrag programma's een SSD herkennen en deze overslaan.

[Vickiieee]

Daarnaast is een SSD ook dusdanig snel dat defragmenteren eigenlijk geen zin heeft. Bij een HDD kan dit nog wel eens helpen als de schijf erg gefragmenteerd is. Alles op volgorde zetten heeft dan nog wel zin, bij een SSD is dit gewoonweg niet nodig.

[dezejongeman]

het is gewoon slecht! voor een ssd. een hdd wil de bestanden netjes achterelkaar op een rij hebben staan zodat data met 1 schrijf kop beweging zoveel mogelijk bijlelkaar horende data kan lezen/schrijven.

een ssd wil bijelkaar horende data juist verdeeld hebben over de verschillende geheugen modules zodat deze tegelijk uitgelezen of beschreven worden (parallel). de aansturing ervan gebeurt door ssd controller. perfect disk wil ook geen defragmentatie doen op een SSD. wel hebben zij nog een trucendoos die optimize heet. die doet wel iets (heb alleen niet meer scherp wat) vermoelijk het herschrijven van bitjes die al wat ouder zijn. zo kunnen deze bits daarna gemakkelijker uit gelezen worden. en ja optimize maakt de ssd wel weer iets sneller althans in de benchmarks.

[joppybt]

Het verspreiden over verschillende geheugenmodules wordt verzorgd door de controller op de SSD. Dat heeft verder niets met defragmentatie te maken. Als een 10% volle schijf 'perfect' gedefragmenteerd is, is het echt niet zo dat alleen de eerste geheugenmodule gebruikt wordt.
In theorie is het zelfs denkbaar dat juist door fragmentatie wél alle bytes van een file op één geheugenmodule belanden. Dan zou defragmentatie de performance kunnen verbeteren. Dit zal echter waarschijnlijk onmeetbaar/ onmerkbaar zijn.

[Barsonax]

Kortere levensduur waar haal je dat vandaan? Van schrijfacties zal die niet snel kapot gaan tenzij je elke dag 100gb aan torrents op je ssd download.

Denk eerder dat ssd's in een hoop situaties veel langer meegaan dan hdd's. Neem laptops bijvoorbeeld die wat meer bewegingen zullen maken dan je desktop pc iets waar een hdd niet altijd goed tegen kan.

[Reactie gewijzigd door Barsonax op 24 juli 2024 20:37]

[roy-t]

Een SSD kan letterlijk maar een X aantal schrijfacties per cell overleven. Dit is een praktisch limiet waar je ook tegen aan kunt komen. Gelukkig kun je na de laatste schrijfactie nog wel alles blijven lezen, je raakt dus niets kwijt. Ook is in veel SSDs een stukje verborgen ruimte die een deel van de kapotte cellen kan vervangen. Maar uiteindelijk zal de SSD er hoe dan ook mee ophouden. Een HDD werkt op een andere manier en heeft geen theoretische limitiet op het aantal schrijfacties per sector. (Maar ze gaan natuurlijk ook af en toe kapot).

[Barsonax]

Ja klopt maar ik had al gezegd in mijn post dat een ssd van schrijfacties eigenlijk niet kapot gaat tenzij je zeer grote hoeveelheden data per dag voor lange periode erheen schrijft. Dus snap de reden van jouw post even niet.

Tegen de tijd dat die eindelijk van schrijfacties kapot gaat is je ssd alweer te klein geworden voor praktisch gebruik en zullen mensen in de meeste gevallen deze alweer vervangen hebben.

[roy-t]

Het ging vooral over 'niet zo snel' en dat HDDs eerder kapot gaan. Ik vrees dat vooral voor goedkope SSDs (met MLC geheugen) het toch tegenvalt. Misschien dat deze na een jaar of 4-5 problemen gaat geven. HDDs heb ik eigenlijk nog niet kapot zien gaan binnen de normale leeftijd van een PC. (Afgezien van die keren dat iemand gewoon verdomde pech had).

[Barsonax]

Ik heb al meerdere testen gezien waaruit blijkt dat een ssd niet binnen een normale levensduur kapot gaat van schrijfacties. Daar moet je gewoon teveel data voor schrijven om dat binnen bijv 5 jaar te laten gebeuren.

Edit: Wanneer ik thuis ben zal ik de link even opzoeken naar zon test.

[Reactie gewijzigd door Barsonax op 24 juli 2024 20:37]

[furian88]

Aanvulling, er zijn programma's die dan automatisch "Trim" uitvoeren op een ssd, dit om de ssd te optimaliseren.

[stresstak]

Misschien een stomme vraag maar heeft dit nog zin met een SSD?

Heeft het uberhaupt nog zin.? Ik vind van niet. Ook bij harde schijven wegen de twijfelachtige voordelen niet op tegen de extra acties van de lees/schrijfarm. Heeft men ooit weleens geluisterd naar de activiteiten tijden het defragmenteren. Over het verkorten van de levensduur gesproken..

[Fealine]

Sorry....? "Twijfelachtige voordelen"? Kan je dat toelichten, aangezien defragmentatie een bewezen techniek is om je HDD sneller te maken en daarbij een langere levensduur te geven, juist door de mechaniek niet te veel te stressen tijdens normaal bedrijf.

Het geluid dat gemaakt wordt tijdens het defragmenteren isexact hetzelfde geluid dat wordt gemaakt wanneer je HDD flink gefragmenteerd is. Dus liever eenmalig de HDD flink stressen dan constant stressen tijdens normaal bedrijf.

[beerse]

IN de begin tijd van de virtualisatie heb ik veel profeit gehad van disk defragmenteren: Een vmware-gast op een mswindows host met 'thin disks'. wil de gegevens nogal verspreid over de fysieke disk zetten.

Door eerst in de gast een disk-defrag te doen en daarna met de gast uit op de host een disk-defrag waren de boot-snelheden serieus veel sneller, vooral met meer dan 2 gasten op 1 disk.

Maar toegegeven, nu met ssd-s en operatingsystems die beloven zelf indien nodig te defragmenteren, gebruik ik zelf deze extra tools pas als ze het weer over optimalisatie gaan hebben: Ook een ssd heeft namelijk af en toe optimalisatie nodig.

[Buggle]

Kort antwoord: nee.
Zuivere theorie: een beetje (een 'beetje' fragmentatie is voor SSD's van groot voordeel, dat werkt als een soort RAID 0. Zodra je echter te veel fragmenten hebt, moeten er meer cellen uitgelezen worden dan per tijdseenheid parallel gebeuren kan. Dus moet je langer wachten. Als al je fragmentjes in dezelfde 4096KB cel staan, dan heb je mazzel. Als ze verspreid staan over 150 cellen, is er meer tijd voor nodig om alle fragmenten bij elkaar te zoeken, als het ware. Natuurlijk gaat dit allemaal in nanosecondengebied, dus veel zul je er sowieso niet van merken. Dit is overigens wat de SSD Optimize van PerfectDisk pretendeert te doen.
Praktijktheorie: het heeft geen zin om te defragmenteren. Omdat de 'map' die je SSD krijgt, potentieel anders is dan de daadwerkelijke layout van je flashchipjes. Eigenlijk is de controller op je SSD, die alle signalen rondstuurt en chipjes dingen laat doen, degene die het bovenstaande uitvoert. Een map, zoals je die in je defragmentatieprogramma krijgt, hoeft dus niet overeen te stemmen met dat wat de controller doet.
Moraal van het verhaal: stel nou dat je zeker weet dat je map en de flash chipjes overeenstemmen, dan kun je defragmenteren voor een zeer minieme theoretische winst. Daarbij moet overigens wel weer gezegd worden, dat vrijwel alle defragprogjes dingen aan elkaar plakken naar het begin van de schijf toe. Dat is niet zo slim bij een SSD, omdat dan de chips onevenredig slijten. PerfectDisk doet dat in die modus dus niet.

En hou toch eens op met die verhaaltjes over dat het heel erg slecht voor je SSD is. Die paar defragmentatiecycles maken op de Terabytes die met normaal gebruik al schrijft echt helemaal niets uit. Moet je het natuurlijk niet iedere dag doen...

[H!GHGuY]

En je maakt zelf de fout door de mapping tables compleet te vergeten. Wat het OS ziet als 'begin van de schijf' kan in realiteit volledig verspreid over de hele fysische NAND zijn.

Je hebt dus de informatie die een SSD bijhoudt over data (bvb hoe oud de data is) volledig weggegooid en enorm veel writes gegenereerd met zeer hoge write amplification (want de drive is zo hard bezig dat hij garbage collection uitstelt en in een vorm van 'direct reclaim' gaat).
Het eindresultaat is dat je drive denkt dat alle sectoren nieuw zijn, dat er enorm veel werk is voor garbage collection en dat je drive de eerstkomende tijd zal spenderen aan garbage collection en terug free blocks maken.

Nee, defragmenteren is echt slecht voor de lifetime en short-term performance van je SSD.

[Buggle]

Juist ja. Ik maak dus helemaal geen fout. Dat is dus precies wat ik zeg:

Omdat de 'map' die je SSD krijgt, potentieel anders is dan de daadwerkelijke layout van je flashchipjes

[H!GHGuY]

Het stukje wat in je "zuivere theorie" staat is fout. Fragmentatie maakt niet plots van je drive een soort RAID 0. Ik begrijp wat je bedoelt: door verschillende blocks in verschillende NAND flashes op te slaan, kan je drive hogere snelheden halen door parallellisatie bij het uitlezen, zoals een RAID 0 dit ook kan.

Echter ga je dan voorbij aan diezelfde mapping tables (niet 'map', het is trouwens verwarrend met het NL woord voor folder in deze context). Net doordat een sector op je disk gemapped wordt, heeft de fragmentatie op filesystem niveau heel weinig effect. Diezelfde sector kan bij wegschrijven op een totaal andere locatie terecht komen dan de naburige sectoren.
In het beste geval passen drives heuristics toe om data die op sector niveau aaneensluitend weggeschreven worden optimaal weg te schrijven of om dit te doen met data die kort na elkaar worden weggeschreven.
De garbage collector zou zelfs kunnen intern defragmenteren door logisch aaneensluitende data wat dichter bij elkaar te zetten, afhankelijk van hoeveel metadata hij hiervoor bijhoudt.

Dus, net zoals defragmentatie zinloos is, heeft ook fragmentatie geen voordeel à la RAID 0.

[Buggle]

Ook daar hebben we het over hetzelfde. Ik heb het niet over fragmentatie op filesystemniveau. Ik heb het over het concept fragmentatie. En dat kan wel degelijk als een soort RAID 0 functioneren - dat is inherent aan het concept, precies zoals je zegt. Het gaat mij om de analogie.
Ik geef vervolgens net als jij aan welke redenen ervoor zijn dat deze theorie niet de werkelijkheid is, om redenen die ik wellicht wat te eenvoudig neerzet en jij meer in detail verwoordt. In wezen hebben we het over hetzelfde en komen tot dezelfde conclusie. Ik probeer in mijn post daarin alleen de theorie van PerfectDisk, en de theorie die niet in de parktijk omgezet kán worden (om bovengenoemde redenen) te verwerken, om beide kanten van het verhaal te belichten.

Ik zou het waarderen als je ophoudt dingen steeds fout te noemen, als woorden voor meerderlij uit te leggen zijn. Jouw interpretatie van mijn woorden maakt mijn woorden pas fout, je hebt namelijk gelijk in wat je zegt. Maar het is niet hoe ik het bedoeld heb, en ook niet hoe het er persé staat...

[H!GHGuY]

Als ik het met die uitleg herlees, komt het inderdaad op hetzelfde neer.
Maar dan had je de overladen en ambigue term fragmentatie beter niet gebruikt, want dat is het helemaal niet. Iets als striping zou de lading beter gedekt hebben.

[Ircghost]

Nee, dit heeft geen zin en is ook nog eens slecht voor de levensduur (veel meer schrijfacties). Ook hebben (eigenlijk) alle ssd's Trimming en auto garbage. Die zorgt ervoor dat je ssd prima blijft lopen.

[Verwijderd]

In tegendeel. Voor zover ik weet wordt het defragmenteren van een SSD zelfs afgeraden omdat het de levensduur van de schijf kan verkorten.

[lenwar]

En daar gaan we wederom.... Een SSD hoef je inderdaad niet te defragmenteren. Je kan echter wel de vrije blokken consolideren. Dit is dan ook iets wat (o.a.) PerfectDisk doet.

Zie hier een (reclame) filmpje:
http://blog.raxco.com/201...wearing-out-its-lifespan/

[H!GHGuY]

En dat is nu eens de grootste BS die er is.

Consolideren van vrije blokken is iets wat een SSD under the hood zelf doet, je kan dit niet triggeren vanuit de host. Het beste wat je kan doen is TRIMmen van de free space en hopen dat de drive bij de eerstvolgende garbage collect waar nodig zelf ervoor zorgt dat ie voldoende volledige lege pages heeft.

Door zelf te lopen rotzooien en files te relocaten ga je trouwens de boel nog meer om zeep helpen aangezien de slimmere drives dan niet meer kunnen bijhouden welke blocks nooit veranderen en welke blocks regelmatig wijzigen.

Niet doen dus, je maakt het enkel slechter.

[beerse]

Ook een ssd kan en moet af en toe geoptimaliseerd worden. En dat moet in overleg met het operatingsystem gebeuren, dus kan een ssd dat niet zelf. Bijvoorbeeld de lege files weggooien, dis-continue, sparce, thin files legen en dergelijke.

Daarnaast bieden veel ssd-s ingebouwde encryptie, die op haar beurt ook af en toe wat werk te verzetten heeft al dan niet in oveleg met het os.

[H!GHGuY]

De enige methode die een OS heeft is TRIM. Daarmee geeft een OS aan welke sectors (512B/4KB) vrij zijn. Een NAND page is typische enkele KB (4-8KB voor gangbare modellen) en een erase block zit in de grootteordes van 512K-1MB.

Zonder TRIM krijg je 4 toestanden per sector in NAND: 2 toestanden voor gebruikte sectors (gebruik en gebruikt voor een verwijderde file) en 2 toestanden voor ongebruikte sectors (vrij en ongewist). Het OS ziet enkel gebruikt vs de andere 3 toestanden, de SSD ziet 'gebruikt', 'ongewist' en 'vrij'. TRIM zorgt ervoor dat 'gebruikt voor verwijderde file' omgezet wordt in 'ongewist'.
Die informatie gebruikt de SSD dan om een beter zicht te krijgen op hoe hij het efficientst moet wear-levellen, waar hij best de volgende sectors moet wegschrijven enz. Dit doet hij door middel van mapping tables die sectors mappen op offsets binnen fysische NAND pages (en erase blocks).
Er is dus geen 1:1 mapping tussen sector 300 vanuit het oogpunt van het OS en dezelfde fysische offset in het NAND memory.
De meeste SSDs houden ook bij hoe lang de data al op dezelfde plek staat. Files van je windows install zullen minder vaak wijzigen dan een swap-file bijvoorbeeld.

Door nu vanuit het oogpunt van het OS allerhande data rond te schuiven, zowel oude data als nieuwe data, ga je eigenlijk alle informatie die je SSD heeft bijgehouden waardeloos maken. Je OS mag dan wel een grote hoeveelheid aaneengesloten free memory zien, door de mapping tables en de manier waarop een SSD werkt kan het alsnog zijn dat die data overal verspreid op je drive staat.

De beste manier is om gewoon TRIM te gebruiken en de logica in je SSD zelf laten uitmaken wanneer hij welke NAND blocks leegmaakt om terug vrijge pages te krijgen.

Ingebouwde encryptie heeft geen onderhoud nodig. De key zit in de SSD en de data wordt symmetrisch versleuteld bij wegschrijven en ontsleuteld bij lezen. Daar komt helemaal geen onderhoud aan te pas.

[beerse]

Precies. En dat dus in een tool met een drukknop. De tool ziet wat vor opslag het is en wat het moet doen voor de optimalisatie.

enneh.. jij denkt dat encryptie in een ssd geen onderhoud heeft. Maar als je gaat trimmen dan kan (zal) het wel mee spelen.

[H!GHGuY]

Niks te tool. Windows, Linux en Mac doen automatisch al TRIM. Waarom dan nog $30 betalen voor een tool die niets bijdraagt en eigenlijk de boel nog erger maakt door de wear-leveling metadata compleet om zeep te helpen.

Nee, ik wéét dat encryptie in de SSD geen onderhoud nodig heeft. Als je tegenbewijs hebt, dan hoor ik het graag.
De metadata blijft hetzelfde, alleen wordt de data voor het fysisch weg te schrijven symmetrisch geëncrypteerd. Als er CBC mode gebruikt wordt kun je zelfs nog data deduplicatie doen.

[Hennie-M]

Ik zie in de changelog ondersteuning voor vSphere 6. Heeft het zin om VM's te defragmenteren?!
Wie heeft er ervaring mee? (3 datacenters, meerdere SAN's)

edit: Yggdrasil, dat was dus precies mijn gedachte. Maar misschien dat iemand een andere use-case heeft om je VM's te willen defragmenteren.

[Reactie gewijzigd door Hennie-M op 24 juli 2024 20:37]

[Yggdrasil]

Ik vraag me af hoeveel zo'n defragmentatietool überhaupt nog te zeggen heeft bij een SAN. Daar zitten meerdere abstractielagen tussen de software en de hardware, zoals logical volume management, raid, etc. waardoor het voor een defragmentatietool toch onmogelijk is om te bepalen waar de data fysiek staat? Ik kan me dus niet voorstellen wat men hier nog kan doen.

[beerse]

Zeker wel. Bijvoorbeeld met vsphere op een san en met thin disks: Dan wil defragmenteren de lege ruimte bij elkaar voegen en als het goed is die ook terug geven aan het san. Aan de andere kant.... het kan ook de san behoorlijk door de war gooien....

[Lanithro]

Wat ik mij afvraag is of dit programma zo veel beter is dan het standaard defrag van Windows.

[Ramoncito]

In the ol' days (..) deed MS defrag alleen de normaal toegankelijke bestanden, kon je het eventueel laten doen vóór het opstarten van het OS (minder gelockte bestanden). De betaalde varianten deden ook bestanden die normaliter niet verplaatst mogen/kunnen worden (systeembestanden, hybernation of gelockte bestanden). Daarnaast bijvoorbeeld ook het verplaatsen van bestanden die vaak geaccessed worden naar het snelle deel van de schijf en grote bestanden naar het uiteinde (om defragmentatie te voorkomen). Ook konden ze sneller werken door geheugen te gebruiken. Maar ja, of het nou die $30 waard was tov van de MS defrag...

[Sebazzz]

Blijf alsjeblieft ver weg bij dit soort software, je ziet het al met wat ze aanprijzen:

PerfectDisk offers the most comprehensive solution for defragmentation by optimizing virtually every file on the system, including the Master File Table (MFT), all NTFS metadata files, paging files, directories, and datafiles, and completely consolidating free space.

Waarom? Simpel: When programs grovel into undocumented structures...

In Windows 2000, there are several categories of things that cannot be defragmented. Directories, exclusively-opened files, the MFT, the pagefile... That didn't stop a certain software company from doing it anyway in their defragmenting software. They went into kernel mode, reverse-engineered NTFS's data structures, and modified them on the fly. Yee-haw cowboy! And then when the NTFS folks added support for defragmenting the MFT to Windows XP, these programs went in, modified NTFS's data structures (which changed in the meanwhile), and corrupted your disk.

Of course there was no mention of this illicit behavior in the documentation. So when the background defragmenter corrupted their disks, Microsoft got the blame.

Grote kans dat het met deze software net zo het geval is, reverse-engineering van Windows internals in een poging om snelheid te winnen.