Administrace komentářů

Jste první, kdo zmínil JFFS2. To je totiž přesně takový FS, který umí pracovat s holými flash čipy, včetně dost dobrého wear levelingu. Obecně log-structured FS. Další byl snad UBI FS...

http://en.wikipedia.org/wiki/JFFS2

http://www.linux-mtd.infradead.org/doc/ubifs.html

Pokud to správně chápu, tyhle flashové FS umí "po svém" pracovat s obsazeností, držet si seznam vadných bloků apod. Holé flash čipy takové režijní informace nemají kam uložit (flash čip je jenom surové pole paměťových buněk) - "zapečená SSDčka" si ten seznam vedou taky v nějaké oblasti flashe, kterou si k tomu vyhradí.

Linux umí s "přímo mapovanými" flashkami pracovat dávno, v linuxové terminologii se tomu říká Memory Technology Device - akorát se tenhle způsob práce s flashkami na trhu SSD hardwaru moc neprosadil. Pokud tomu správně rozumím, fungují tak na úrovni hardwaru některá high-endová PCI-e SSDčka (flash sběrnice JEDEC/ONFI apod. je mapovaná přímo na PCI nějakým jednoduchým bridgem), ale v tom případě je translace na 512B sektory provedena closed-source ovladačem. Spousta PCI-e SSDček naopak obsahuje větší počet (s)ATA-flash kontrolérů a k nim větší počet kanálů HBA, případně ještě s dedicated RAIDovým procesorem

Mimochodem větší velikost sektoru pro Linux a jeho FS taky není problém - tohle se dávno vyskytuje na RAIDech, svého času jako metoda jak obejít 2TB bariéru. Fakt je, že je normální v této souvislosti mluvit třeba o 4kB sektorech (což by odpovídalo NAND Flash stránce=řádce, nebo-li minimální transakci typu čtení/zápis na flash čipu), ale těžko třeba o 512 kB - 4 MB (erase blok flashky).

Výše uvedený JFFS2 jsem potkal mnohokrát, ale fakt je, že to bylo tuším vždycky na NOR flashkách - typická velikost v jednotkách MB a používají se na firmware různých ARM/MIPS/MCU (a taky PC BIOS), mají o pár řádů menší kapacitu než SSDčkové NAND flashky. Jestli nějaký linuxový FS umí pracovat konkrétně s NAND flashkami, to netuším...

V linuxu existuje taky softwarová "translační vrstva" pro NAND flashky: umí pracovat s NAND médii, navenek prezentuje blokové zařízení - na kterém můžete mít EXT2/3/4 apod. Jmenuje se NFTL resp. iNFTL. Svého času se používala s flashdisky od M-Systems (řádově jednotky až nízké stovky MB) - než firma M-Systems zkrachovala. Nijak se mi nestýská - hardware co šel zrovna koupit měl vždycky o něco novější revizi firmwaru (vlastně BIOS option ROM), takže to věčně nefugovalo apod. Docela jsem si oddechl, když se rozšířily CompacfFlashky a další ATA Flash formáty, které měly translační vrstvu zapečenou v hardwaru (což je nám dneska přesně trnem v oku).

S MTD je ten problém, že dosavadní implementace nemají jednotné rozhraní vůči OS. Různé embedded krabičky na bázi ARM/MIPS/MCU, pokud loadují Linux nebo nějaký RTOS, mají toto ošetřeno předáváním parametrů z bootloaderu, a/nebo kompilací jádra na míru. Pokud mělo z MTD bootovat PCčko, musela být součástí/doprovodem flashdisku BIOSová option ROMka, která obsahovala implementaci "translační vrstvy" - a pak byly potřeba dedicated ovladače v OS, které translační vrstvu "převzaly" (viz právě M-Systems DiskOnChip). V linuxu se tomu říká "plaftorm-specific device" (nebo prostě "platform device"). V tomto ohledu je rozhraní ATA/SATA/SAS velikým přínosem - právě protože potřebujete ovladač pro HBA a dál se neptáte, jaký disk je na to připojen. Prostě je to další "jednotící mezivrstva". Že je to zrovna v případě flashek "přes koleno", to je smutné - ale zatím myslím nikdo nepřišel se standardizovaným jednotným způsobem, jak připojit flashky "rovnou cestou" na PCI sběrnici, tak aby pro to pak stačil jednotný driver. Napadá mě zařídit pro to PCI device class a jednotné ovládání, něco jako EHCI nebo AHCI, ovšem pro MTD. A pak by se možná musel standardizovat i nějaký jednotný FS, aby z toho šlo bootovat, pokud je takový požadavek... => zrovna tohle je spíš cesta do pekel (programming by committee, lobbing z různých stran apod.)