F2FS: nový souborový systém pro flash paměti (diskuse)

[erino72]

Myslite ze sa ujme aj na iných android devices, alebo len samsung? Aky je defaultny FS?

[Attila Tóth]

Rád by som to videl u foťákov, usb kľúčov, nech sa toho microsofťáckeho trola zbavíme v podobe FATu.

[xvasek]

Myslím, že flash přístupná přímo a flash přes USB je trochu něco jiného. Pokud je tam řadič, chová se to jako normální blokové zařízení, ale pokud je přístup přímo, tak jsou ty operace takové dost obskurní.

[klusik]

Hmm, to by mohlo být i zajímavé na SSD, žejo.

Každopádně nevidím růžově, že bychom se zbavili FAT a podobných přežitků; když vidím, že se pořád masově prodávají DVDplayery, které umí JEN FAT a titulky načíst jen v CP1250 a o UTF nikdy neslyšely... že nepochopí MKV, to už se ani nedivím. Dokud si budeme uměle udržovat "dinosaury", tak jsou tyhle nápady hezké, ale...

Nu co, ale, tak třeba zrovna tento nápad rozbije konzervativce, že. Ale už ani nečekám, že by widle začaly podporovat (byť přes nějaký driver nebo interface) ext4...

Tohle rozbití škodí všem...

[Redi]

EXT4 na widlích funguje přes nějakou appku... Ale je to dost polovičatý...

[ovoce]

Pro SSD nevím. Dneska ten řadič/firmware dělá psí kusy s realokováním bloků a rozkládáním zátěže, často si to dokonce reorganizuje při nečinnosti. Takže použití těch různých systémů psaných na tělo holé NAND mu (tipuju) v lepším případě nepomůže, v horším možná i ublíží.

[Luboš Doležel (Doli)]

Tyhlety FS bývají primárně určené pro RAW flash, ne?

[little.owl]

Ano. U normalnich usb flashek nebo ssd je to k nicemu. Tohle je uzitecne pro embedded systemy behajici primo na raw flash, kdy je treba implementovat wear leveling.

[Jindřich Makovička]

Hlavně je FAT uvedená přímo ve specifikaci SD karet. A pro SDXC je standardem exFAT, takže v budoucnu bude situace ještě horší.

[ovoce]

Právně jo, ale útěchou budiž, že už nebude limit 4 GB na velikost souboru.

[xvasek]

Mám 8GB USB flash a chci tam nainstalovat Debian a mít to jako záchranný disk, ale aby tam fungovala i persisitence a aby to bylo plnohodnotné distro. Teď mám Debian live s persistencí, ale ten UnionFS (navíc s ext2) se mi moc nelíbí a hlavně to žere moc místa. Co tam dát za FS?

[noname123]

Ja na HP Micro serveri mam Debian Wheezy na 16 GB USB kluci, normalna instalacia s EXT4, bez swap oddielu a funguje to perfektne.

[xvasek]

Asi to udělám podobně - našel jsem u ext3 parametr "commit", kde se dá nastavit, jak často má updatovat žurnál, přijde mi to lepší, než ext2. Chci mít tu flashku bootovatelnou na různých PC včetně Gnome, už se mi to hodněkrát osvědčilo. Co je zarážející, tak každý kout internetu popisuje, jak udělat Live CD, ale systémem instalovaným na USB flash se nikdo moc nezabývá, přitom Live CD mi přijde bez persistence dost o ničem a persistence na flash přes unionFS (a ext2!) je dost nestabilní a taková divná.

[motyq]

jakou flashku mate? zrovna to ted resim, protoze mi odesla deska na domacim nasu, takze to chci hodit na nejaky amd zacate + usb flash.

Akorat porad nevim co vybrat.

Pocitam, ze napr logy hodim do ramky, swap taky vypnu... mam flashku vybranou nejaky patriot axle 8GB. Nenasel jsem totiz (drive jsem o to nekde zavadil) usb flashku s pinama, ktera sla zastrcit primo do zakladni desky - misto kabelu kterym se vedou do predniho/zadniho panelu bedny dodatecne usb porty... a sata diskonmodule uz je moc drahy - to se mi nechce davat...

[lertimir]

Konečně. Dva roky píšu kde to jde o nutnosti principielně nového FS pro flash disky a konečně začínám mít dojem, že tyhle nápady mají i jiní.

[Michal Kubeček]

Nápad je jedna věc, realizace druhá… (Tím chci říct, že to, že teprve teď někdo poslal do LKML návrh implementace, zdaleka neznamená, že to doteď nikoho nenapadlo.)

[lertimir]

to jasně, ale nemluvilo se o tom že na tom někdo pracuje.

[petr_p]

Existující YAFFS a podobné systémy je co?

[lertimir]

To nejsou filové systémy pro desitky a stovky GB data.

[xvasek]

Hlavně a zejména to není na SD kartu nebo USB klíč.

[petr_p]

Jenže na SD nebo USB nemáš přístup k NAND. Takže celá ta složitost s počítáním sektorů je zbytečná a stačí nasadit libovolný souborový systém, který není optimalizován na rotační média a který umí trim.

[little.owl]

+1

Jenže na SD nebo USB nemáš přístup k NAND.

Ano. Tam je controller mezi NAND a FS, ktery v podstate vsechny vyhody F2FS odstini. Tenhle FS miri o level nize, nez se pohybuje 99% uzivatelu PC.

stačí nasadit libovolný souborový systém, který není optimalizován na rotační média a který umí trim.

Presne tak, staci trim.

[little.owl]

A jak vam to pomuze? Tohle je filesystem pro bare NAND flash, kolik ze jich doma provozujete? Standardni SSD ci USB flash to nejsou.

[lertimir]

Podle odkazu do diskuse na Slashdot pracuje i nad blokovým zařízením. Takže bude i pro SSD. A hlavně používané file systémy mají hodně hluboko v designu zasazené optimalizace pro rotační disky, třeba přednačítání dat při průletu hlaviček, způsoby rozdělování inode po prostoru, snaha o defragmentizaci atd. Flash je v podstatě pro read pomalá paměť z náhodným přístupem a žádnou penalizací za dlouhé skoky. Zato má penalizace pro mnoho malých zápisů, pro mazání, a omezenou životnost jednotlivých buněk. To co samozřejmě SSD a v omezení míře USB flash dělají je flikování těchto vlastností v hardwaru tak, aby file systémy pro rotační disky byly použitelné.

A podobně jak jsem do nějaké diskuse tady psal asi před rokem, směřují design do logově orientovaného filesystému, takže fragmentace bude obrovská, což nevadí, a zápisy do jednotlivých buněk málo časté, což pomůže. Jsem zvědav, kdy flash disky začnou do smart tabulek hlásit skutečné parametry disku, jako velkosti erase block, rychlosti erase.

[little.owl]

pracuje i nad blokovým zařízením. Takže bude i pro SSD.

Fajn. Jenze FTL, wear leveling a cele mapovani je u SSD provadeno internim controllerem, tutiz tohle nema zadny benefit.

NAND flash v praxi pouzivam, vim co tam jsou za problemy.

[lertimir]

Ale to je přesně to flikování. Na to abychom byli schopni použít na flash staré file systémy určené pro rotační disky, zavedeme do fyzického zpracování záplaty, které jakž takž umožní, aby staré file systémy byly schopny fungovat a flash nezničily.

Dokud nebude opravdu dobrý (nebo alespoň slušný) filesystém, který bude pracovat s flash tak jak je hardwarově udělána a využívat jejích silných stránek, tak samozřejmě výrobce SSD bude dělat hardwarové flikování, aby prodal s tím, že na tom pojede filesystém pro rotační disky. A nedělám si iluze, že to půjde rychle. Podobně jako trvalo léta, než se file systémy propracovaly do dnešní podoby.

První mašiny, s nimiž jsem pracoval, se krmily děrnými štítky a OS/360 na IBM maiframech používal pro přístup k diskům metody nazývané Basic Direct Access Method (BDAM), což byly mírně přepsané metody pro přístup k páskovým jednotkám Basic sequential access method (BSAM). A než se vyvinuly dobré filesystémy pro rotační disky, tak to trvalo hodně dlouho. V podstatě ve stejné situaci jsme nyní: Používáme starou technologii na novém fyzickém HW, který má velmi jiné vlastnosti. Tehdy se v jistém smyslu přistupovalo k disku jako k páskovému zařízení s velmi rychlým seekem, rewindem a převíjením FF. (můžu nad diskem přemýšlet i takto, ale naprosto nevyužiji jeho vlastnosti) a stejné je to i teď se SSD a flash discích, vlastně se k němu chováme tak, že je to disk s rychlým seek timem mezi stopami, ale není. Je to v podstatě paměť a jak s ní efektivně pracovat se musíme postupně naučit, tak jak jsme se naučili, jaké má disk nové vlastnosti vůči páskám.

[petr_p]

Obávám se, že zaměňujete příčinu a následek.

Podle mě souborové systémy pro velké paměti nejsou, protože všechny velké paměti se prodávají s řadičem, a tak je nikdo nevyvíjí.

Důkaz, že není problém je vytvořit, je právě YAFFS a ostatní systémy. Ty vznikly ještě před existencí velkých pamětí, protože tehdy existovaly jen malé paměti a ty se neprodávaly lidem, ale montovaly se do zařízení, kde se Windows téměř nevyskytují.

Naopak když se začaly vyrábět velké externí paměti, tak kvůli rozšíření Windows bylo jasné, že nic jiného než VFAT nebo NTFS nepřipadá v úvahu. Ostatně výrobcům pamětí nutnost řadiče přišla vhod, protože to je to jediné, čím si mohou konkurovat (protože skutečné nandové pole vyrábí jen pár firem), a je to jedna z mála možností, jak vytvořit nové proprietární duševní vlastnictví na čem postavit firmu.

Nakonec někdo tu již psal, že standard pro Secure Digital vyžaduje VFAT. Stále vám připadá, že ten zlý jsou linuxoví vývojáři?

[lertimir]

Já ale netvrdím, že zlý jsou linuxoví vývojáři. To v žádném případě. A ta vazba mezi designery flash disků (musíme tam dát řadič, který zamaskuje vlastnosti a bude se chovat jako blokové zařízení s malými sektory, protože jinak to nikdo nekoupí protože to nemůže provozovat) a programátory systémů (v flash disku je řadič, který mě flash převede na block device a tak s tím nebudu nic dělat) je taky zřejmá. Stejně tak je zřejmé, že dokud do hry nevstoupí někdo s velkých hráčů (Microsoft, IBM, Oracle, možná i Google) s tím, že vyvine pro své použití filesystem pro flash tak se patrně nic nezmění, protože nikdo jiný nepřesvědčí výrobce aby tam měli jiné řadiče, které respektují HW vlastnosti toho flashe, např tak, že reportované bloky budou erase bloky toho flashe. Optimalizace ve file systému, jak pracovat s blokem, který má 1M a omezený počet zápisů by byla zcela jiná. Teď tu optimalizaci se snaží řešit řadiče v flash discích, ale díky tomu, že mají vždy jen velmi lokální informaci, tak to sice funguje, a v porovnám s disky rychle, ale kolik potenciálu těch flash disku to nechá nevyužité.

A YAFFS a další jsou v jistém směru první pokusy, podobně jako FAT, na prvním IBM PC s 360kB disketami a 10 MB HDD jsem si myslel, jak je to úžasná koncepce. Ale skutečné file systémy pro HDD jsou samozřejmě jiné. A kolik to dá práce je vidět na btrfs. Začli v roce 2007, tedy po 5 letech, když už mají btrfsck, tak se dá o tom uvažovat jako hotovém file systému. Podobně to trvalo před lety u SUNu a SGI s ZFS a XFS. To co mě mrzí a trochu štve je že se na tom FS pro flash moc nedělá.

[David Jaša]

Optimalizace ve file systému, jak pracovat s blokem, který má 1M a omezený počet zápisů by byla zcela jiná. Teď tu optimalizaci se snaží řešit řadiče v flash discích, ale díky tomu, že mají vždy jen velmi lokální informaci, tak to sice funguje, a v porovnám s disky rychle, ale kolik potenciálu těch flash disku to nechá nevyužité.

Kolik je toho nevyužitého potenciálu v situaci, kdy zapisovací blok je zlomečkem bloku mazacího, a řadič má díky TRIM docela dobrou představu o tom, kdy má se zapisovacími bloky hrát škatule a nebo kdy je má nechat na místě?

[lertimir]

Už třeba to, že elementární zapisovací blok NAND chipů je "page" která je tuším v současnosti 2048+64 bytů přičemž flash disk reportuje OS standardní 512B bloky. To když by systém věděl, že zapisovací page má 4x větší, mohl by se podle toho zachovat. To že to lze flikovat je zřejmé. Ale pořád si myslím, že když by systém věděl jaké má zařízení fyzické parametry tak by se s tím mohl mnohem lépe vyrovnat. třeba tak, že by zapisoval skutečně celé stránky, nebo tak, že by si v jednotlivých erase blocích stavěl něco jako logový záznam a věděl, jak ho zaplňuje případně ho optimalizoval.

Spíše mne zarazilo, jak tvrdíte, že s těmi flash, je to prostě fajn, tak jak to je a není třeba nějakých změn.

[David Jaša]

ext systémy umí nastavit velikost dvou úrovní bloků (stride/stripe a block) - pokud je nastavíš na velikost zapisovacích a mazacích bloků, jaký bude rozdíl ve výkonu oproti flash s "řadičem ve filesystému"?

[juju]

mna by zaujmalo strašne ako ste dostali debian intalaciu na USB klúč , keďže pomne vyžaduje stale swap , a ten neviem nijak preskočiť a aký usb klúč by mal byť najvhodnejší