SSD ti nikdy nikam nic kontinualne nezapise, protoze jako prvni prepise bunku ktera ma nejnizsi citac. A jakym zpusobem jsou ty bunky rozhazeny ty nemas naprosto zadnou moznost zjistit.
Pokud je SSD vicemene plne, tak ma jen dve moznosti. Neustale osoupavat ty zbyvajici bunky. Nebo setrvale presunovat data. Coz pochopitelne vede k tragickym vykonum.
Specielne, kdyz bezna velikost ty bunky je MB a vic ... zatimco vetsina fs se drzi 512B per sektor.
To je jasné, že ty konkrétní fyzické adresy samozřejmě přímo neovlivníš. Já jsem spíš myslel víceméně kontinuální zápis z hlediska LBA a pořadí celých souborů při kopírování zpět ze zálohy po jejich předchozím kompletním smazání a TRIMu.
Ano fyzická alokace záleží na spoustě faktorů. Bere se v potaz např. seznam vadných bloků (i s nějakými výchozími záznamy už z fabriky), nějaký optimální proklad pro paralelizaci, tak i zmíněné informace o počtu zápisů, kvůli wear levelingu .. plus tam bude celá řada dalších a většinou proprietárních optimalizací.
U té logické alokace to také není nutně zcela lineární a určitě hraje roli konkrétní file systém a jeho nastavení (jinak se bude chovat ext4, XFS s alokačními skupinami a třeba ZFS).
Nicméně přes tohle všechno tímhle celým procesem po určité době standardního používání výrazně defragmentuješ jak filesystém, tak i fyzické uložení. Při kopírování na prázdné SSD v podstatě při foldingu/GC budou brát celé volné bloky bez potřeby dalších RMW cyklů. A jak jsem už říkal, udělá se v rámci možností víceméně optimální proklad. Také pak na konci kopírování zbyde v porovnání s výchozím stavem typicky daleko vyšší počet celých volných bloků, což může u některých modelů ovlivnit i velikost dynamické SLC cache.
Proklad je jeden ze znatelných problémů, který třeba řeší výzkumníci ze Samsungu. Po nějaké době používání, kdy se zvýší fragmentace a ty sekvenční části souboru jsou pak nerovnoměrně rozložené mezi čipy (jsou tam hotspoty), se prodlužují latence při čtení.
Ještě jen k terminologií (aspoň jak ji používám já).
chip -> die -> plane -> block -> page (subpage) -> cell
Nejmenší část s daty je cell.
Nejmenší část pro čtení je page (někdy i subpage, jak to pojmenovávají někteří výrobci, když je SSD přepnuté do režimu kompatibility, kde použitá menší než nativní page), mívá třeba 4-16 Kb.
Jak zmiňuje RDa, tak nejmenší část která se dá přeprogramovat je blok, který má něco jako 64 nebo 128 stránek (což je asi ten 1 MB, co jsi psal).
Jinak filesystém pak má dneska spíš 4kB velikost bloku (clusteru u NTFS), ne 512B.
Což mě vede ještě k jedné věci, která mi přijde, že tu občas v diskuzích trochu zapadá. V praktickém používání hraje velkou roli i optimalizace na úrovni blokové vrstvy a IO scheduleru. Ten například standardně spojuje krátké requesty podle jejich LBA. A to až do maximální délky requestu, co podporuje HW. Tzn. když tam bude v nějakém čas. intervalu hromada kratších write requestů (např. 4k bloky fs) s vzestupným adresováním, bude se to spojovat až do 1M requestů, co se pak následně budou posílat do disku. Jinak ještě tohle logicky nejde dělat, když ty zápisy neprochází přes page cache, tzn. např. režimy s direct nebo sync.
Podobně jdou spojovat i nekontinuální čtení nebo zápisy do jedné operace s pomocí scatter-gather listů, což pak třeba hardwarově podporují některé novější NVMe disky.
41 Odpovědí
9106 Zhlédnutí