TRIM op NTFS

[Xudonax]

Allereerst, ja, dit is inderdaad een vreemd topic voor Non-Windows Operating Systems. Dat ben ik helemaal met jullie eens. Maar.

Ik heb een 32GB Sandisk SSD die via Qemu doorgegeven word aan Windows. So far, so good. Echter, dit is een oude caching SSD en er zijn dus praktisch geen vrije sectoren meer. Qemu meld echter niet aan Windows dat dit een SSD is, dus Windows doet geen TRIM. En NTFS-3g doet ook geen TRIM. Geen probleem dacht ik, we maken gewoon met dd een bestand aan dat alle ruimte vult zodat dat stuk schijf leeg is, doen vervolgens een secure erase op de schijf en knikkeren dan de image terug. Maar ja, dit schiet natuurlijk niet op omdat ik nu weer data schrijf naar een hoop sectoren die gewoon leeg zijn

Nu zit ik dus nog met een bestand van ~17GB welke met dd if=/dev/zero of=test.bin bs=8M is aangemaakt. Nu wil ik alle sectoren die door dit bestand in gebruik zijn een TRIM commando sturen (om het even zo te noemen), maar ik heb geen idee hoe dat moet. Ik weet dat hdparm dit kan, en ook dat ik hiervoor --trim-sector-ranges nodig heb. Ook heb ik gelezen dat ik met --fibmap <file> een lijst met LBA sectoren krijg die door het bestand ingenomen worden. Echter, deze lijst is gigantisch gefragmenteerd, en wat moet ik met de offset doen?

Ik heb heel geen moeite om dingen uit te gaan rekenen en uit te zoeken, maar ik kom er even niet meer uit...

Het begin van het resultaat van hdparm --fibmap /media/part2/test.bin:

code:

$ sudo hdparm --fibmap test.bin 

test.bin:
 filesystem blocksize 4096, begins at LBA 718848; assuming 512 byte sectors.
 byte_offset  begin_LBA    end_LBA    sectors
           0   14930128   14932775       2648
     1355776   15003032   15004175       1144
     1941504   15270432   15270503         72
     1978368   15509632   15516511       6880
     5500928   15639048   15640311       1264
     6148096   15910888   15914687       3800
     8093696   16175816   16184783       8968
    12685312   16269376   16281303      11928
    18792448   16303440   16305503       2064
    19849216   16460416   16461071        656
    20185088   16690120   16690143         24
    20197376   19077400   19077407          8
    20201472   19301608   19301631         24
    20213760   19802240   19802335         96
    20262912   19871200   19873015       1816
    21192704   20187488   20547071     359584
   205299712   20570672   20570807        136
   205369344   20693248   20693375        128
   205434880   20843112   20843239        128
   205500416   21067752   21128343      60592
   236523520   21131392   21132311        920
   236994560   21276104   21276759        656
   237330432   21439424   21439471         48

[Rainmaker]

Allereerst; heb je op KVM ook de discard optie geactiveerd op de disk?

http://wiki.qemu.org/ChangeLog/1.5

Block devices
IDE and SCSI disks always have the ability to issue "discard" (aka TRIM or UNMAP) commands. However, by default "discard" commands are silently ignored as they can cause performance degradation and fragmentation. To enable them, the "-drive" option now supports a "discard" suboption; the default value is "ignore" (or its synonym "off"), and the other valid value is "unmap" (or "on").

Second, als je een SCSI device passthrought kun je m.i. beter vanuit Windows de TRIM commando's doen. Dan weet je namelijk ook meteen of de emulatielaag dit ondersteund.

Op Linux systemen is het simpel; filesystem mounten en hierna een

code:

fstrim /mnt

geven.
Ik ken zo geen commando om alleen blokken behorend tot een bepaalde file te TRIMmen. Usecases lijken me ook zeer beperkt, en bovenstaand verhaal lezend is het me ook absoluut niet duidelijk welk probleem je hier nou precies mee wil oplossen en waarom je denkt dat TRIM commando's je hier een oplossing kunnen bieden.
Zoek je niet eerder zoiets: https://wiki.archlinux.or.../SSD_Memory_Cell_Clearing

Maar goed, het kan natuurlijk wel, maar dan zul je dit zelf in C moeten coden.
Zie hier voor een voorbeeld: http://code.metager.de/so...sybox/util-linux/fstrim.c

Je zult met dit C progje een FITRIM ioctl call moeten doen.
De magische regel in dit bestand is xioctl(fd, FITRIM, &range);, zie http://man7.org/linux/man-pages/man2/ioctl.2.html

[Xudonax]

Ik heb de discard optie in KVM niet enabled nee, ik wist niet eens dat dat bestond
Eens even kijken hoe ik die via libvirt erin ga krijgen.

Wat ik wil bereiken is heel simpel. De SSD is hiervoor gebruikt als L2ARC (cache) disk voor mijn ZFS systeem. Hierdoor is er heel veel naar geschreven zonder enige vorm van TRIM oid. Ik wil dus inderdaad de memory cells clearen zodat ik hopelijk weer een beetje performance terug krijg.

Maar eerst maar eens even naar die discard optie van KVM kijken

EDIT: Ugh, mijn libvirt versie verwijderd de discard='unmap' optie Naja, dan de SSD maar imagen en vanaf een image gaan draaien

[ Voor 12% gewijzigd door Xudonax op 01-03-2014 12:01 ]

[Rainmaker]

Zie de link die ook in mijn reactie stond: https://wiki.archlinux.or.../SSD_Memory_Cell_Clearing

On occasion, users may wish to completely reset an SSD's cells to the same virgin state they were manufactured, thus restoring it to its factory default write performance. Write performance is known to degrade over time even on SSDs with native TRIM support. TRIM only safeguards against file deletes, not replacements such as an incremental save.

Klinkt als precies waar je naar op zoek bent.

Maar is geen TRIM