TRIM á SSD diskum orðið barn síns tíma

[gardar]

Rakst á skemmtilega umræðu um TRIM á linux póstlista um raid.

Blocks that are unused by the filesystem still have to be carried around by the SSD if they are not TRIM'ed, and that is extra work. But it is not actually a great deal of extra work. In particular, filesystems do a lot of re-use of deleted blocks - when the logical block is re-written, the SSD knows that the old data is no longer needed.


The main purpose of TRIM, and the reason it was introduced, was not so much to avoid moving around unneeded copies of old data, but to make sure there are free erased blocks available when they are needed. With modern SSDs with over-provisioning and better garbage collection, that is no longer necessary - there are always free blocks, since there are many more physical blocks than logical ones.


If TRIM were well implemented, then it could still have been useful. But it is a synchronous command, and cannot be queued - this means it is slow, and breaks the flow of commands. So the result is that operations such as "delete" can take many times longer to complete if TRIM is enabled.

Mér hefur einmitt alltaf þótt TRIM undarlegur hlutur, software lausn á hardware vandamáli.

[hjalti8]

Rakst á skemmtilega umræðu um TRIM á linux póstlista um raid.

Blocks that are unused by the filesystem still have to be carried around by the SSD if they are not TRIM'ed, and that is extra work. But it is not actually a great deal of extra work. In particular, filesystems do a lot of re-use of deleted blocks - when the logical block is re-written, the SSD knows that the old data is no longer needed.


The main purpose of TRIM, and the reason it was introduced, was not so much to avoid moving around unneeded copies of old data, but to make sure there are free erased blocks available when they are needed. With modern SSDs with over-provisioning and better garbage collection, that is no longer necessary - there are always free blocks, since there are many more physical blocks than logical ones.


If TRIM were well implemented, then it could still have been useful. But it is a synchronous command, and cannot be queued - this means it is slow, and breaks the flow of commands. So the result is that operations such as "delete" can take many times longer to complete if TRIM is enabled.

Mér hefur einmitt alltaf þótt TRIM undarlegur hlutur, software lausn á hardware vandamáli.

hmm, svo að trim á ekki að skipta eins miklu máli útaf innbyggðu garbage collection-i á nýjum diskum?

skil þetta nú ekki alveg ,hvað á að vera slæmt við trim? ég get ekki betur séð en að trim skiptir miklu máli á sandforce diskunum skv testi frá xbitlabs:



http://www.xbitlabs.com/articles/storag ... html#sect0

[Mr. President]

Það er ekki rétt að segja að TRIM sé software lausn á hardware vandamáli heldur er það eiginlega öfugt. Þegar þú 'eyðir' gögnum á gamaldags harðdisk þá eru gögnin ekki yfirskrifuð heldur eyðir stýrikerfið bara pointer sem vísar í gögnin og segir hvar þau eru. Það er gert vegna þess hve harðdiskar eru hægvirkir og tæki annars langan tíma að eyða gögnum. Ef þú ætlaðir að eyða t.d. 10gb af gögnum þá myndi diskurinn annars þurfa að skrifa 10gb. TRIM er frekar viðsnúningur á þessu; þegar þú eyðir gögnum á SSD þá segir TRIM disknum að þurrka gögnin út (eða núllstilla blokkirnar) eins og harðdiskar myndu hafa gert ef þeir væru ekki of hægvirkir. Gallinn er bara að eldri stýrikerfi gerðu ekki ráð fyrir þessu.

Garbage collection er svo annar handleggur. Overprovisioning ætti að hjálpa til en það er misjafnt milli framleiðenda hvernig GC virkar. Ég er t.d. með Agility3 þar sem það virkar alls ekki nógu vel; ég var með 20gb linux partition (sem ég eyddi) og það var ekki fyrr en ég skrifaði 20gb af rusl gögnum og eyddi aftur í Win7 (sem triggerar TRIM) að ég fékk leshraðann upp aftur. Munurinn var um 100mb/sek.