Sync-Faking, da kommt er aber zu einer Zeit mit dem Thema an.....
Also es kommt von den RAID Controllern, hier kannst Du schon mal was dazu lesen:
http://peter-zaitsev.livejournal.com/12639.html
Hier steht auch noch was:
Programmierer nennen es auch fsync-faking, weil die C-Standardfunktion fsync für das Leeren des Caches verwendet wird, bei Linux (und auf sysinternals auch für Windows) ist sync aber ein Befehl um das Leeren von Schreibcaches des Systems und auf den Laufwerken auszulösen. Auf SATA Ebene wären das die Befehle FLUSH CACHE - E7h oder FLUSH CACHE EXT - EAh (bei Laufwerken die 48bit Adressierung unterstützen) und darf maximal 30s dauern.
Datenbanken und auch Benchmarks (wie der
AS-SSD Benchmark) führen nach Schreibvorgängen einen sync aus um der Datenbanken eben die Konsistenz der Daten sicherstellen zu können, weil sie sicher sind, dass die Daten so auf dem Datenträger stehen, wie sie geschrieben wurden. Das Faken besagt, dass der Befehl sofort als ausgeführt behandelt wird, ohne die Daten wirklich auf die Datenträger zu schreiben und es kommt von den RAID Controllern mit BBU, die einen Datenverlust auch bei plötzlichen Stromausfall nach Ende des Befehls wegen der BBU vermeiden können (eine Zeitlang wenigstens). Dann ist das dann auch erlaubt, eben weil sichergestellt ist, dass die Daten nach dem sync auch bei plötzlichen Spannungsabfälle eben nicht verloren gehen und daher haben SAS/SATA RAID Controller mit BBU eben auch per Default andere Schreibcacheeinstellungen als ohne und schreibend mehr IOPS und schaffen vor allem bei Datenbankanwendungen mehr Performance.
SSDs machen das aber auch, z.B. viele von OCZ und auch SSDs mit Sandforce Controllern (keine Ahnung ob alle und auch die von Intel es haben) haben das auch, nur haben die keine Stützkondensatoren, zumindest nicht die Consumerversionen und damit ist es dann eben nicht "erlaubt" bzw. wird eben u.U. problematisch, weil der Rechner denkt, ob die Daten sind geflusht, der Strom kann aus. In Benchmarks bringt das auch viel, weil diese eben wie viele reale Programme auch oft am Ende ein fsync absetzen und dann erst nach dessen Ende die Timer stoppen. Wird das sync gefakt, ist die Schreibrate im Benchmark natürlich höher.
Bei den Stützkondensatoren muss man auch zwischen den
Lösungen für Enterprise SSDs, also den Full-Power-Loss Protections und denen für Client SSDs unterscheiden, letztere haben kleinere Kondensatoren und schützen nur die Data-at-rest, nicht aber wie die Full-Power-Loss Protection auch die Userdaten im Schreibcache und natürlich dürfen nur letztere Sync-Faking betreiben. Von den Retail SSDs haben nur die Intel 730 (wenn auch nicht offiziell) und die Intel 750 eine Full-Power-Loss Protection, die Crucial mit Marvell Controllern ab der m4 und auch die OCZ Vector 180/VR180 haben nur die kleinen Client Lösungen, die Vertex460A und die anderen OCZ mit dem Barefoot3 Controller haben gar keine Stützkondensatoren.
Wie kann man das nun feststellen? Indem man die Schreibcacheeinstellung von Windows für die SSD ändert. Normalerweise sieht die so aus:
Bencht man so die SSDs mit dem AS-SSD, dann kommen da die normalen Schreibraten raus wie man sie aus Reviews kennt, nimmt man den Haken raus (beim Systemlaufwerk ist dann erst Reboot nötig damit die Einstellung übernommen wird), kommen viel schlechtere Schreibwerte raus, vor allem bei 4k Schreibend sind es nur weniger MB/s. So sieht es bei einer MX100 aus:
(
Bildquelle)
Die macht also kein Sync-Faking, dagegen macht die OCZ Vertex4 es, den wie man sieht liegen die Unterschiede bei den Schreibraten im Rahmen der Messtoleranz und weit über dem, was NANDs ohne Schreibcache schaffen können:
(
Bildquelle)