LanyFS: souborový systém pro vyjímatelná média

Zajímavý, že dvojtečky v Redmontu vadí a alternativní datové streamy, dlouhé názvy souborů či přejmenování základních adresářů ne.

Ano, což je úplná hloupost, to by měla být jenom konvence a ne že to ovladač souborového systému vynucuje.

Dvojtečky a otazníky jsou rezervované znaky. U NTFS je to věc API, u exFAT je to obsaženo v návrhu FS. Důvod je jasný: rezervované znaky mají speciální význam. Kdyby to tak nebylo, bylo by potřeba všechno escapovat, jako na unixech. A na unixech je s tím spousta problémů. Řada skriptů (kterými jsou tyhle systémy prolezlé) má dodnes problém i s pouhou mezerou v názvu. Než escapovat (což by bylo potřeba naučit každého kdo otevře command line), tak raději rezervované znaky.

Počet souborů v adresáři omezený na 2796202 je podle vás problém, když hovoříme o removable mediu? Zkoušel jste někdy výkon nějakého unixového FS, když máte v adresáři o řád méně souborů? Bývá to dost tragické. Nemluvě o aplikacích. Zkuste si vzít nějaký file manager na Linuxu (samozřejmě single-threadový, jak je dobrým zvykem), a vlezte do takového adresáře. Až si uvaříte kafe, můžete pokračovat v práci. A ty atributy? To jsou dva bity, podle mě celkem nuda.

exFAT samozřejmě umí ochranu metadat, pomocí TexFAT. Spotřební elektronika ale nic podobného nepoužívá, protože by byla implementace zbytečně složitá.

Šifrování a komprese na exFAT není opět z kvůli snahy jednoduchost a snadnou implementaci.

UDF je naprosto nesmyslně složitý. Nakonec i to je důvod, proč je kompletních implementací UDF pomálu.

Ano, při používání GUI je hrozně potřeba escapovat názvy souborů. Že jsem si toho ještě v Linuxu nevšiml :-)

Řada skriptů na Unixech má problém s mezerou v názvu a stejný problém má řada skriptů i ve Windows a MS přesto mezeru nezakázal. Skripty, které si hlídají mezery, si spolu s ní hlídají i všechny ostatní speciální znaky.

Na XFS ani ext s dirindexy takový počet souborů není moc problém. A pořád nechápu, proč je to tak nesmyslně omezené, když třeba za deset let už nebude vůbec problém takový adresář vypsat ani ve Windows. Zřejmě je to nějaké rozhodnutí stylem 2796202 files ought to be enough for everybody.

Jediný singlethreadový souborový manažer, který mám, je mc a ten s tím moc problémů nemá.

TexFAT ale nepoužívají ani stolní Windows. Navíc je tak skvěle navržený, že implementace, které jej nepodporují, připojený TexFAT doslova rozmrdají (smazat žurnálu při připojení? nezájem), proto jej MS na přenosná média nedoporučuje.

Šifrování mohlo být volitelné rozšíření. Když zkusíte otevřít šifrovaný soubor v zařízení, které ho nedokáže přečíst, tak prostě nic nepřečte. Výhodou by byla standardizace.

UDF je možná nesmyslně složité, ale ve Windows je implementované téměř úplně. Jen je nesmyslně omezeno na optické disky.

Hm, zkuste si na nějakém unixu nainstalovat aplikaci do adresáře obsahujícího mezeru, slash nebo otazník :)

Řekl bych "2796202 files in one directory on USB key ought to be enough for everybody for next couple of years" :). Nevím co myslíte tím "není moc problém". Akce nad adresáři s velikým množstvím souborů jsou prostě pomalé.

Fakt už máte na Linuxu běžně multithreadové file managery? Když jsem se naposledy odvážil otevřít /etc ve file manageru (už si nevzpomínám kterém), tak se i na těch pár souborech na pár vteřin úplně seknul.

Opravdové transakční FS jsou složité na implementaci, mají poměrně vysokou režii, a nevidím moc důvodů je používat na klíčenkách. Při nejhorším se po dalším vložení klíčenky provede repair FS. Když jste vyškubnul klíčenku v půlce kopírování souboru, bude soubor holt poloviční.

Šifrování je k dispozici pro NTFS, na úrovni volume i souboru. Proč do jednoduchého FS cpát takovou věc?

Ano, Windows formátují na UDF pouze optické disky.

No super. Teď to zkuste ještě u Oraclu, SAPu, Lotus Notes, MySQL a OpenOffice.
BTW zmiňoval jsem se o tom escapování. Než escapovat, to snad raději reserved characters.

Jak jsem psal. Pokud to zvládne mezeru, zvládne to i otazník. Mezery ve Windows celkem fungují, fungoval by tedy i otazník. Slash je vyhrazený proto, že odděluje adresáře, což má alespoň smysl vyhradit. (Btw. NTFS otazník umí.)

Aha, a potom to budeme řešit podobně jako v DOSu :-)

Jsou pomalé jenom při prvním načtení. Pak jsou v cache a jsou dost rychlé. Teda pokud máte nějaký rozumný operační systém.

V KDE jsou všechny aplikace, které mohou provádět nějaké dlouhé operace, multithreadové. V GNOME předpokládám taky, ale to nemám.

Proto se používá žurnál, který je na implementaci poměrně triviální, na rozdíl od repair FS. A bez repairu se ta metadata nedokáží opravit, takže bude dost nebezpečné takový disk používat.

Protože je pro přenosná média a snaží se tvářit jako moderní. Nebo je šifrování opět protiamerické?

Kdyby jen formátují, oni neumí neoptické disky s UDF ani číst nebo na ně zapisovat, pokud nejsou speciálně připravené.

To samozřejmě není pravda. Pokud chcete v názvech souborů používat wild chars, musíte nutně escapovat. A escapování je úplně zbytečná komplikace. Uvozovky okolo jména souboru se při troše štěstí naučí i moje babička, přestože je dávno mrtvá. Escapovat backslashe a uvozovky je daleko složitější, a museli bychom to učit každého, kdo si otevře command line.

Ještě jednou: zkuste si těch 2796202 souborů do adresáře uložit, provádět na nich nějaké operace, a případně otevřít takový adresář ve file manageru. Až to zkusíte, přijďte si o tom znovu povídat. Já zkoušel na unixech daleko menší počty souborů v adresáři, a výsledek nic moc.

Napsat žurnálový FS není problém, i když při pohledu na historii některých unixů může mít člověk jiný dojem :). Problém je opět ve složitosti toho FS. FAT je možné implementovat v pár stovkách bytů, a exFAT má být na dnešní poměry podobně jednoduchý. Pokud chcete žurnál, kompresi, šifrování, ACL, kvóty a transakce, nevybírejte si jednoduchý exFAT. Je tu třeba krásné NTFS, které umí tohle všechno a ještě víc :)

Vaše babička otevírá command line? Já jsem slyšel něco o tom, že ve Windows to není třeba. Alespoň to někdo (vy?) dával jako velké plus oproti Linuxu. (Btw. použijte apostrofy, tak není potřeba escapovat)

Implementací žurnálu vzroste složitost výrazně méně než implementací repair. Ale evidentně v Redmontu nikdy nešlo o bezpečnost uživatelských dat, takže ani repair se zřejmě implementovat nebude :-)

Problém je, že z disku naformátovaného na NTFS ten embedded systém nepřečte ani ty data, co nejsou šifrovaná ani komprimovaná.

Neotevírá, protože je mrtvá, ale jinak by mohla :). Apostrof nepomůže, když je ve jménu souboru apostrof. Proč to komplikovat? Rezervované znaky jsou daleko jednodušší koncept, který na rozdíl od escapování, single quotes a double quotes každý snadno pochopí.

Nechci vám to kazit, ale nástroj pro opravu FS je potřeba v každém případě.

Pokud máte jednodhcý embedded systém typu MP3 přehrávače nebo fotorámečku, nepoužívejte NTFS, ale exFAT. Pokud váš fotorámeček tak nutně potřebuje šifrování, šifrujte přímo soubory na extFAT.

Pokud s těmi znaky neumíte pracovat v command line, tak proč je jednoduše nepřestanete používat? V GUI žádný problém nedělají. Ale netvrďte nám, co je používat umíme, že je lepší, když nemůžeme. Mimochodem, jak bez escapování vlezete do adresáře %PATH%, což je povolené jméno?

Není. Pokud bude souborový systém v takovém stavu, že bude muset být opraven, tak embedded zařízení může klidně uživateli říct, že je nutné jej zformátovat nebo opravit v počítači (jak to mimochodem už teď dělá s FAT32). K něčemu takovému dojde jen výjimečně (typicky jen když odejde médium), na rozdíl od nekonzistence kvůli vyjmutí během zápisu, která je u SD kart velmi běžná.

Vidím že ten Windows shell moc neznáte. Nepřekvapí.

OK, zkusím to. Zkuste cd ^%PATH^%
Až to budete mít hotové, projděte si for /?, if /? a set /?. Nejspíš zjistíte pár dalších věcí, které jste neznal.

Zkusím si tipnout, že se tam půjde dostat pomocí "%PA""TH%", ale cmd.exe neznám tak moc, abych si byl jistý. Nicméně tolik k escapování :-)

LOL, adresář %PATH%. Přiznávám, že jste mě dostal.

Nekonzistenci při vyjmutí zařízení během zápisu se můžete vyhnout pouze dvěma způsoby: 1. použít plně transakční FS (takže se změny odrolují, včetně změn v datech), 2. nevyjímat médium během zápisu. Ve všech ostatních případech může dojít na nějakou formu problému.

Pokud nekonzistencí myslíte chybějící data v souboru, tak to sice uživatele nepotěší, ale souborový systém bude fungovat dále. Pokud ale myslíte poškozená metadata, takže by se mohlo například stát, že soubor bude odkazovat na blok dat, který je volný, což už vyžaduje opravu, tak to právě řeší žurnál. TexFAT je pro embedded zařízení poměrně zbytečný overkill, ale nebránil bych se mu, kdyby byl alespoň kompatibilní s exFAT nebo fungoval na stolních Windows.

Žurnál je užitečná věc, ale pro foťák nebo MP3 player celkem zbytečná. Znamená to větší footprint.

TexFAT je volitelné rozšíření exFAT, takže je logicky kompatibilní. Na stolních Windows se typicky používá NTFS, takže vás to tam netrápí.

TexFAT není kompatibilní s exFAT, resp. použití TexFAT jako exFAT má hodně zajímavé (a nebezpečné) následky

Dokumentace má chybu. Transakční FAT je TFAT, a transakční exFAT je TexFAT. Jestli chcete, můžete na stránce nahlásit bug report :)

Alokační bitmapa sama o sobě nezlepší výkon při paralelním zápisu více streamů. Tahle optimalizace je hlavně o kvalitě alokátoru.

Alokátor ale nemá s návrhem souborového systému nic společného.

Alokátor je součástí implementace FS. Něco málo o alokaci bloků na FS:
http://www2.cs.uregina.ca/~hamilton/courses/330/notes/allocate/allocate.html

Jak píšu, je to nezávislé na návrhu a stejný alokátor by fungoval stejně nad jakýmkoliv jiným souborovým systémem s alokačními bitmapami

A já myslel, že jste tvrdil následující: "ta úžasná optimalizace pro ukládání několika HD streamů je alokační bitmapa".
http://www.root.cz/zpravicky/lanyfs-souborovy-system-pro-vyjimatelna-media/430583/

Ano, ta úžasná optimalizace je v návrhu exFAT, o kterém se celou dobu bavíme, alokační bitmapa

Ještě jednou: alokační bitmapa sama o sobě nemá s touhle optimalizací nic společného. Proto je vaše poznámka úplně mimo.

V tom případě je úplně mimo ta vaše poznámka, že takhle optimalizace pro exFAT vůbec existuje

Mě přijde jako důležitý rozdíl, jestli FS zvládne nebo nezvládne zápis více streamů najednou se slušným výkonem. Možná vám to přijde mimo; mě ne.

Jenže to není vlastnost FS, ale implementace (navíc neoriginální) jeho alokátoru, který by to samé zvládl na kterémkoliv FS s alokační bitmapou, takže to o tom FS neříká vůbec nic.

Pro výrobce i uživatele je celkem důležitý fakt, že taková implementace existuje. Samozřejmě podobnou alokační strategii lze implementovat i u jiných FS.

Po vybalení z krabice umí exFAT Windows od verze XP/2003, Windows CE a MacOS X od verze 10.6.5. Vyjma toho existuje implementace pro DOS, Linux a Android. A jak jsem psal, SDXC (nová SD-card), Memory Stick XC a nové klíčenky používají exFAT jako default FS. Tím pádem exFAT umí nebo bude umět i spousta spotřební elektroniky, včetně té s Linuxem.

Ale ale. To by se například SDHC karty nikdy neprosadily. Oproti SD(SC) kartám vyžadují nový řadič a podporu FAT32. A co se stalo? Najednou začala na trh padat zařízení s podporou SDHC karet, včetně podpory FAT32. Pro starší zařízení jste holt musel použít starší typ karty. A dnes? Koukněte se, jak výrobci chrlí produkty se čtečkami SDXC karet (pochopitelně s podporou exFAT), a to včetně notebooků s Win/MacOS, foťáků, tabletů i telefonů s Androidem. Pořád tu pravděpodobnost vidíte stejně?

To si musíte koupit nová zařízení, která podporují SDXC. Starší telefony s Androidem umí jen FAT32, novější (minimálně některé) i exFAT.

Já se do telefonů s Androidem nehrabu, ale údajně například Samsung Galaxy S3.

No vida, takhle Samsung myslí na uživatele :)

Windows Phone ale nepřečte žádné klíčenky :)

Jak jsem psal: pokud vám nevadí, že takový FS nemůžete přečíst mimo Linux, tak s tím přece není problém. Mluvím o ext4; LanyFS snad přečtete na poči toho studentíka, když budete mít štěstí.

ext2/3 ve Windows nepřečtete na čisté instalaci systému. Vyžaduje instalaci FS driveru. Nakonec se správným driverem přečtete i NTFS na Linuxu, kvalitních implementací existuje několik (odhaduji že všechny placené).

ext2/3 ve Windows nepřečtete na čisté instalaci systému. Vyžaduje instalaci FS driveru.

Ano, to je mi opravdu výstavně u Ballmerovy prdele.

Jenže ext3 ovladač pro Windows se klidně může dostat i do čisté instalace, stačilo by, kdyby MS chtěl. Linuxový ovladač exFAT se ale do čisté instalace Linuxu dostat nemůže kvůli patentům.

No tak vy jste se uz musel uplne z toho placenyho trollingu zblaznit.

Uz s tema radoby SD vsudybylkama, az po to NTFS v Lin jadre. MS jde dolu, Apple nahoru (bohuzel) a Google jen ceka, az se stane stejnou svini a bude si platit podobny bojovniky jako vy (no, uz to urcite dela).

Ale 50 mil. Americans can't be wrong! (dosad firmu)

Podpora exFAT je součástí nějakého SP pro WinXP.

FS na klíčenkách není o alternativách, ale o interoperabilitě. Uživatel prostě chce klíčenku nebo SDXC kartu na jednom místě zapsat a na druhém přečíst, a neřešit technické detaily. Samozřejmě bychom na removable média mohli používat FS s otevřenou specifikací. Kdyby ho tedy někdo napsal v dostatečné kvalitě, a přesvědčil výrobce k jeho používání.

JFFS2, YAFFS, LogFS, NILFS. Stačilo by, kdyby MS zase nevynalézal kolo, navíc ve stylu Golgafrinčanů.

Mea culpa. Je potřeba SP2+, a poté ještě ten update.

Confíteor Deo omnipoténti et vobis, fratres, quia peccávi nimis cogitatióne, verbo, ópere et omissióne :)

ext4 funguje třeba i na MacOS X a Linux je i Android.