Software-update: Smart Defrag 6.3.0

IObit heeft versie 6.3.0 van Smart Defrag uitgebracht. Met dit gratis programma kunnen de bestanden op de harde schijf worden gedefragmenteerd, wat een gunstige invloed op de prestaties van het systeem kan hebben. Hierbij kijkt Smart Defrag naar welke bestanden vaak worden geopend en welke tijdens het booten van de computer worden gestart, om daaraan dan prioriteit te geven. Defragmenteren levert doorgaans prestatiewinst op bij een traditionele harde schijf, bij ssd's is het echter minder zinvol. Net als de andere gratis tools van IObit, attendeert dit programma af en toe op het betaalde Advanced SystemCare. De changelog voor deze uitgave ziet er als volgt uit:

Changelog:

• Verbeterde gebruikersinterface voor een betere gebruikservaring.
• Geoptimaliseerd registratieproces om het makkelijker en stabieler te maken.
• Het af en toe voorkomende probleem bij het weergeven van Schijf Opschonen resultaten is verholpen.
• Andere kleine bugs zijn verholpen.

Versienummer	6.3.0
Releasestatus	Final
Besturingssystemen	Windows 7, Windows 8, Windows 10
Website	IObit
Download	http://update.iobit.com/dl/smart-defrag-setup.exe
Bestandsgrootte	15,27MB
Licentietype	Freeware

Reacties (21)

[Jester-NL]

Ik kan me werkelijk niet meer herinneren wanneer ik voor het laatst een harde schijf heb gedefragmenteerd en daar ook daadwerkelijk iets van heb gemerkt...
Ik denk dat dat nog was toen ik met W2k werkte.

[bartje]

Vanaf Windows 7 worden hdd’s in Windows automatisch gedefragmrnteerd. Dat hoeft dus niet meer handmatig. Bij ssd’s wordt dat niet gedaan omdat het nut hier minimaal is.

[DukeBox]

..omdat het nut hier minimaal is.

Buiten wat er al gemeld is, het nut is zelfs 0. Fragmentatie op HDD's zorgt er voor dat data niet meer sequentieel gelezen kan worden en daardoor zijn er meer verplaatsingen van de kop nodig om alle data te verzamelen en dat kost meer tijd. Bij een SSD heb je geen bewegende delen, ergo kost dat geen extra tijd.

[Reactie gewijzigd door DukeBox op 24 juli 2024 15:07]

[guillaume]

Voor zover ik weet is dat niet correct. Defragmatie kan op SSD's wel degelijk tot prestatiewinst leiden: het bestandssysteem heeft namelijk bij het uitlezen van bestanden nog steeds met extra overhead te maken als het bestand zwaar gefragmenteerd is. De MFT kan er onnoemelijk groot door worden en voor ieder fragment wordt een nieuwe leesopdracht ingezet.

De tijdswinst van defragmentatie is dus niet op "mechanisch" niveau, maar op het niveau van het bestandssysteem.

@MrFax

[Reactie gewijzigd door guillaume op 24 juli 2024 15:07]

[DukeBox]

In theorie heb je gelijk maar ik vraag mij af of het überhaupt meetbaar is.
Daarnaast hangt het sterk van het filesystem af. De huidige NTFS versie maar ook het veel gebruikte ext4 fragmenteerd files vrijwel niet meer tenzij de disk/partitie vol is. En dan kom je ook weer op het punt dat bij gemiddeld gebruik het niet verstandig is een SSD helemaal vol te gooien.

[guillaume]

Ik weet niet of je kunt stellen dat er nauwelijks fragmentatie optreedt als er bij mij nu 3276 gefragmenteerde bestanden (94360MB) zijn waarbij er 44260 fragmententen "teveel" zijn op mijn SSD met NTFS. (UltimateDefrag)

Schijf is voor 67% gevuld ("men" zegt wel eens dat de prestatie bij 70% begint te kelderen)

[Reactie gewijzigd door guillaume op 24 juli 2024 15:07]

[DukeBox]

Ik gok dat dat voornamelijk de slack space is tussen files in en maar weinig files opsplitst in twee of meerdere delen.

[guillaume]

Nee, da's niet de definitie van "excess fragments".

"If a file is divided into three fragments it has two excess fragments. So, the higher this number, the longer it takes to read this file."

[MrFax]

Er is wel tijdswinst op mechanisch niveau, omdat bestanden dichter bij elkaar staan zijn er mechanisch minder verschuivingen van de head. Dat lijkt me wel logisch Al is die winst zo miniscuul dat je er in praktijk niks van merkt(op mechanisch niveau), maar in theorie wel.

[Reactie gewijzigd door MrFax op 24 juli 2024 15:07]

[guillaume]

Ik heb 't over SSD's.

[MrFax]

Ik reageerde op dat de prestatiewinst op SSD's eigenlijk helemaal niks is, omdat er geen winst te behalen valt op mechanisch niveau, alleen zoals jij zei, op bestandssysteem en driver niveau, maar dat is in praktijk helemaal niks.

Soms merk je er met de combinatie van mechanisch en bestandssysteem prestatiewinst nog iets van, maar dat is het dan ook.

[Reactie gewijzigd door MrFax op 24 juli 2024 15:07]

[mikesmit]

Sterker nog. Defragmentatie sloopt je SSD gewoon aangezien elke sector op de geheugen chip maar een maximaal aantal keer beschreven kan worden. Het laatste wat je wilt dan is een stukje software die eventjes alles gaat schuiven en opnieuw rangschikken

[MrFax]

Je kan dus ook geen SSD defragmenteren via de ingebouwde GUI, want het is inderdaad compleet nutteloos. De reden dat defragmentatie vaak werkte is omdat dit de random I/O iets omhoogschroeft omdat de minder vaak naar andere delen van de spindisk hoeft te schuiven. Bij SSD heb je geen bewegende onderdelen en is defragmentatie echt in praktijk de meest nutteloze ding dat je kan doen.

[Reactie gewijzigd door MrFax op 23 juli 2024 11:34]

[dennis_rsb]

Windows 10 herkent als het goed is een SSD en doet trim softwarematig via de "ingebouwde defragmentatie" en de overige harde schijf/schijven defragmenteert ie wel.

[hatex]

Bij de eerste kleine ssd types was men huiverig een ssd vaak te beschrijven. Ssd's zijn inmiddels een stuk beter (wear leveling) en groter. Zou haast zeggen "die ga je niet meer slijten". Dus defragmenteer als je wil, zolang je niet elke seconde je hele disc wiped zal het wel loslopen. Qlc zal er vermoedelijk t minst blij mee zijn

Trim is geen defrag voor zover ik weet doet het dan ook niks met je fat. Trim wist de als "niet meer nodig zijnde" sectors alvast zodat je niet eerst moet -wissen / schrijven maar direct kan schrijven.

Ik heb serieus een keer meegemaakt dat een systeem met ssd sneller werd van een defrag vermoedelijk omdat de fat table zo veel entries had dat t (oude) os last van lag had.... na defrag was t weg... andere verklaring heb ik r niet voor

[Reactie gewijzigd door hatex op 24 juli 2024 15:07]

[dennis_rsb]

Pfoe zou kunnen, maar ik heb een installatie nooit dusdanig lang in gebruik dat ik last van zoiets krijg denk ik. Ik laat t gewoon aan Windows over, ik vertrouw erop dat die het wel goed regelt.

[MrFax]

TRIM werkt iets anders dan je zelf zegt. Een moderne SSD heeft blocks van 128*4kB. Hoe kleiner een block van pages, hoe preciezer de SSD-controller stukjes data kan verwijderen.

Een SSD kan geen individuele pages verwijderen. NAND storage moet een hele block verwijderen voordat het een page kan herschrijven. Dit komt omdat om data te verwijderen, de block geëlectrocuteerd moet worden om deze leeg te maken, en het vrijwel onmogelijk is om deze voltage te isoleren naar individuele pages, omdat er best een hoge voltage gebruikt moet worden om deze leeg te maken.

Zodra er iets geschreven moet worden naar een page in een block, terwijl hier al data aanwezig is gebeurt er dus dit:

- Eerst wordt de hele 512kb block gekopieerd naar cache.
- De hele block wordt daarna verwijderd van de NAND storage.
- De nieuwe informatie wordt daarna herschreven naar de ongeldige pages in de block(in cache).
- De herschreven block met nieuwe informatie wordt geschreven naar de verwijderde block.

Deze hele procedure heet "Write amplification".

De reden dat oude SSD's na een tijdje heel langzaam werden, is omdat zodra de reserve van lege blocks op waren, de SSD eerst de bovenstaande procedure door moest gaan om nieuwe data te schrijven in lege ruimte.

Daarom doet een moderne SSD aan garbage collection. Elke SSD-controller doet dit anders en is dus lastig uit te leggen. Wat ik wel uit kan leggen is dat TRIM hand in hand gaat met de garbage collection van de SSD:

Met TRIM laat de OS de SSD weten welke pages verwijderd mogen worden, waarna de garbage collector deze informatie gebruikt om efficienter blocks/pages leeg te maken voor nieuw gebruik.

Zonder TRIM zou de garbage collector pas weten welke pages verwijderd zijn door de OS zodra de OS over deze ongeldige data heen wil schrijven. Lijkt me logisch waarom dit inefficient is voor GC.

[Reactie gewijzigd door MrFax op 24 juli 2024 15:07]

[Jay47]

Same here
Dat is echt lang geleden, nog nooit gedaan bij Win 7 en 10.

[Kraz]

Op een SSD schijf wordt het juist ten zeerste afgeraden om dit te doen.

En het zit in principe al ingebouwd in de firmware, waardoor het automagisch gebeurd: TRIM

[Magic Power]

Trim is geen defragmentatie. Trim geeft HD-ruimte vrij aan de SSD-controller zodat die het weer kan gebruiken. Defragmentatie verplaatst al bestaande data op een schijf.

[lenwar]

TRIM heeft niets te maken met defragmenteren. Met TRIM worden niet langer gebruikte datablokken alvast gewist zodat dit niet hoeft te gebeuren bij een schrijfactie. Op deze manier is een schrijfhandeling dus (iets) sneller.

Defragmentatie zorgt ervoor dat grotere hoeveelheden data sequentieel gelezen kunnen worden waardoor de kop van de hdd minder hoeft te bewegen of te wachten tot de data voorbij komt op de draaiende schijf.

Aangezien het besturingssysteem niet eens ziet waar de data op de SSD zit (de SSD controller stuurt wel iets naar het besturingssysteem, vanwege de manier dat opslagapparaten worden aangesproken), kan het besturingssysteem dus niet eens bepalen of er überhaupt fragmentatie zou zijn op de chips.

De enige overeenkomst tussen defragmenteren en TRIMen is dat het veelal op dezelfde plek in een grafische interface te vinden is.