Vad händer med StoreMI över tiden.

2. ser ut som att datat flyttas mot långsammare media först när när det börja bli brist på plats i SSD för data som bedöms av algoritmen har högre prioritet.

Av det så tolkar jag att den långsammare lagringen och den snabbare måste följas åt och om någon av dessa går sönder så har man kraschad filsystem varav delen som är långsam lagring går sönder så kanske det inte märks direkt men efter ett tag då alla vilande skrivningar inte kan utföras mot den långsammare lagringen och begäran om block som inte finns på SSD men finns på långsamma lagringen inte kan effektueras.

bcache som används under linux så har jag för mig att det synkar mot disk/långsammare lagring ganska så fort efter en skrivning (parametrar som det går att skruva på om man vill), men även där finns ju risken i en kort stund att det som filsystemet tror är skrivet - har inte landat på de långsammare diskarna ännu och det kan bli problem om SSD plötsligt tas bort/går sönder i processen - och så kan man gå vidare till HBA med batteribackuppad minne - även där finns det risk för glapp vid problem då filsystemet har fått klartecken att allt är OK innan datat verkligen har landat på volymlagringen...

Samma sak som när man slår på skriv-cachen på snurrdiskar, att det ger kvittens att datat är lagrat innan det egentligen är det... - och allt är ju för att jaga snabbhet på bekostnad av säkerhet.

3. eftersom datat verkar ligga kvar i SSD tills det blir nedknuffad mot snurrdiskarna först när högre prioriterad data begär plats så kommer förmodligen en defragmenterings-session inte att fungera alls eller väldigt illa om det uppfattas som prioriterad data och det tar tid innan det migrerar ned till den långsammare lagring. beror säkert också på hur mycket som flyttas runt också.

Jag tror att fragmenteringsdelen har lite påverkan i detta fall.
Förr när man bara körde mekaniskt så kanske det fanns ett anledning till att defragmentera. När du kör SSD eller hybrid så är tidskillnaden så liten för en hårt fragmenterad disk jämfört med en helt defragmenterad disk.

Jag tror inte att Windows defrag kan hantera den mekaniska disken för den kommer inte ha ett traditionellt filsystem där defrag kan läsa var enskilda filer ligger och således kan den inte heller veta var en fil börjar och slutar.

Du kommer säkert kunna defragmentera StoreMI-volymen men det kommer bara skapa kaos för algoritmen som försöker hålla reda på vilket data som är Hot och vilket som är Cold.

Men som sagt detta är bara vad jag tror och ingen erfarenhet av just StoreMI.

NTFS är extrem när det gäller fragmentering , speciellt för en viss typ av användning som torrent och utan att köra preallokerade filer, att även en SSD behöver defragmenteras ibland - inte lika ofta som en snurrdisk men kanske någon eller ett par gånger per år.

Det beror på att om en mediafil som består av 10000 extent tar längre tid att sätta ihop till en fil med kanske en krav på minimum garanterad fart än om samma fil består av 7 mycket större extent. Även om SSD kan arbeta väldigt mycket snabbare än en snurrdisk så påverkas inläsningstiden ändå om filerna är väldigt mycket fragmenterade - och en hög fragmentering gör också tex. att TRIM inte fungerar då filsystemet måste frigöra ett antal Mbyte sammanhängande data innan SSD internt kan radera blocket och det räcker med en enda sektor som inte frigörs för att hela blocket skall låsas och inte kan förberedas för snabb skrivning eller att agera som skriv-cache för somliga versioner av SSD.