hier war mal einer mit einer vollverschlüsselten Indilinx im Windowslaptop, bei dem brachen die writes auch mal auf 20MB/s ein.
wie die SSDs mit writecombining funktionieren steht zb. hier
http://lwn.net/Articles/353411/
http://www.anandtech.com/storage/showdoc.aspx?i=3631&p=4
zb. hier wegen spare
http://www.haifa.ibm.com/conferences/systor2009/papers/2_2_2.pdf
auf Seite 9 ist der Zusammenhang zwischen write amplification und spare.
Der Zusammenhang zwischen Schreibleistung und spare wird wohl ziemlich ähnlich oder gleich sein (bzw. invers).
es gibt auch noch die OCZ Lösung (gc-firmware 1.41), die die garbage collection einfach stärker optimieren lässt, zb. für RAIDs und andere Leute die nicht trimmen können. Allerdings sinkt dadurch die Lebensdauer.
Als ich noch nicht trimmen konnte habe ich einfach die Idee von Ted Tso ausprobiert
http://thunk.org/tytso/blog/2009/02/22/should-filesystems-be-optimized-for-ssds/
Und wie schon gesagt, blieb alles schön schnell.
wie die SSDs mit writecombining funktionieren steht zb. hier
http://lwn.net/Articles/353411/
http://www.anandtech.com/storage/showdoc.aspx?i=3631&p=4
zb. hier wegen spare
http://www.haifa.ibm.com/conferences/systor2009/papers/2_2_2.pdf
auf Seite 9 ist der Zusammenhang zwischen write amplification und spare.
Der Zusammenhang zwischen Schreibleistung und spare wird wohl ziemlich ähnlich oder gleich sein (bzw. invers).
es gibt auch noch die OCZ Lösung (gc-firmware 1.41), die die garbage collection einfach stärker optimieren lässt, zb. für RAIDs und andere Leute die nicht trimmen können. Allerdings sinkt dadurch die Lebensdauer.
Als ich noch nicht trimmen konnte habe ich einfach die Idee von Ted Tso ausprobiert
http://thunk.org/tytso/blog/2009/02/22/should-filesystems-be-optimized-for-ssds/
LVM mit 3 logischen Volumes gemacht für ubuntu, ubuntu-home, fedora mit 25, 20, 20GB. Also eher knapp bemessen, aber groß genug um übermäßige Fragmentierung zu verhindern und klein genug um jede Menge spare zu haben. Wenns zu knapp ist kann man die volumes/filesysteme ja später immer noch vergrößern.Until ATA TRIM support becomes available, it will be advantageous to add support in ext4 for a block allocator option that aggressively reuses blocks above all else, and avoids using blocks that have never been allocated or used before, even if it causes more in-file system fragmentation and deeper extent allocation trees. The reason for this is at the moment, once a block is used by the file system, at least today, the X25-M has absolutely no idea whether we still care about the contents of that block, or whether the block has since been released when the file was deleted. However, if 20% of the SSD’s blocks have never been used, the X25-M can use 20% of the flash for better garbage collection and defragmentation algorithms.
Und wie schon gesagt, blieb alles schön schnell.
Zuletzt bearbeitet: