Vlákno názorů k článku
LanyFS: souborový systém pro vyjímatelná média
od Jarda_P - Problem je, ze nez MS opatchuje Widle, tak...
-
Lael Ophir (neregistrovaný)
Proboha proč kvůli implementaci jednoho FS hrabat do kernelu? Ve Windows to můžete implementovat prostě jako driver file systému. Nevidím ale důvod, aby MS implementoval ve Windows minimalistický studentský FS, který má podle ohlasu vývojářů linuxového kernelu dost mizerné vlastnosti.
http://msdn.microsoft.com/en-us/library/windows/hardware/gg463062.aspxNa výměnná média můžete používat FAT32, a pokud potřebujete soubory větší než 4GB, tak exFAT. ExFAT má vestavěnou podporu na Windows, v MacOS, a existují i implementace pro Linux. Navíc exFAT je default FS pro nové karty SDXC (nová SD-card) a Memory Stick XC, takže za chvíli uvidíte jeho podporu i u foťáků a další spotřební elektroniky.
-
Lael Ophir (neregistrovaný)
Těmi zbytečnostmi myslíte optimalizace, které umožňují například číst a ukládat několik HD streamů najednou s minimalistickými nároky na HW?
http://www.tuxera.com/products/tuxera-exfat-embedded/benefits/ -
Sten (neregistrovaný)
Těmi zbytečnosti myslím třeba zbytečně omezené množství znaků, které lze použít v názvech (třeba dvojtečky nebo otazníky se běžně vyskytují v názvech filmů a ty debilní Windows je ani ve 21. století neumí), nesmyslně omezený počet položek v adresáři (alespoň že limit není tak malý jako u FAT, ale stejně to moc hezky ukazuje, jak v Redmontu neumí pracovat s pamětí), nesmyslné atributy (system? archive? to jako vážně?). Na druhou stranu tomu chybí jakákoliv ochrana integrity metadat, což je pro moderní přenosný souborový systém, obzvlášť na kartách, které někdo snadno vyjme bez odpojení, katastrofa a chybějící šifrování jistě taky potěší (NSA, nikoliv uživatele).
Navíc to má nejen uzavřenou specifikaci, ale ještě je to prošpikováno patenty a vnucováno z pozice síly (MS nemá ve Windows žádný otevřený systém kromě UDF, kterému úmyslně znemožňuje fungovat na čemkoliv kromě optických disků).
-
Ale predstavte si ty moznosti. Poskytuje vam to jistou miry ochrany dat i v zemich, kde je zakaz sifrovani nebo zakony na key escrow. Zazipujete do souboru s dvojteckou ve jmene, policajt si poridi kopii souboru, pripoji to ke stroji s Widlemi a je v zakonceni zazivaciho traktu. Neotevre to, kdyby se i kdyby se poradil se sluzebnim psem.
-
Lael Ophir (neregistrovaný)
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.
-
Sten (neregistrovaný)
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.
-
Lael Ophir (neregistrovaný)
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.
-
> Hm, zkuste si na nějakém unixu nainstalovat aplikaci do adresáře obsahujícího mezeru, slash nebo otazník :)
[root@silver tom]# whereis ls
ls: /bin/ls /usr/share/man/man1/ls.1p.gz /usr/share/man/man1/ls.1.gz
[root@silver tom]# mkdir "/medzera ? \\slash"
[root@silver tom]# ls / | grep medze
medzera ? \slash
[root@silver tom]# mv /bin/ls "/medzera ? \\slash"
[root@silver tom]# export PATH="/medzera ? \\slash":$PATH
[root@silver tom]# whereis ls
ls: /medzera ? \slash/ls /usr/share/man/man1/ls.1p.gz /usr/share/man/man1/ls.1.gz
[root@silver tom]# ls
1 log
1.wav log.0
2011.csv log.0.lck
2012-2b.csv log.1
2012-2c.csv log.2
2012-2.csv log.3
2012-3b.csv log.4
(...)
-
> BTW zmiňoval jsem se o tom escapování. Než escapovat, to snad raději reserved characters.
Sila zvyku, slash v uvodzovkach escapovat netreba. Inak Vasej nechuti k escapovaniu nerozumiem, _ne_pouzivat znaky, ktore treba escapovat mozem rovnako dobre na oboch systemoch.
> No super. Teď to zkuste ještě u Oraclu, SAPu, Lotus Notes, MySQL a OpenOffice.
Myslim, ze tu narazame na Vasu neznalost linuxovych systemov. Instalacia (napriklad) OpenOffice nelezi v jednom adresary, je ako kazda spravna aplikacia rozdelena na /usr/bin, /usr/lib a /usr/share. Kazdy z tychto adresarov mozem pomenovat lubovolne a jediny, kto z toho bude mat totalny gulas bude uzivatel :)
-
Sten (neregistrovaný)
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é.
-
Lael Ophir (neregistrovaný)
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 :)
-
Sten (neregistrovaný)
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á.
-
Lael Ophir (neregistrovaný)
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.
-
Sten (neregistrovaný)
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á.
-
> Mimochodem, jak bez escapování vlezete do adresáře %PATH%, což je povolené jméno?
Ciste technicka, cmd.exe (windowsacka parodia na shell) escapovat nevie, takze sa do adresara %PATH% nedostanes vobec. Nepomozu dokonca ani uvodzovky, nakolko v obycajnych premenne expanduje a ine nepozna.
Jediny sposob, ako sa da taky adresar pouzit je pouzit expanziu *PATH* a aj to funguje len ak to podporuje program alebo prikaz (nakolko pod Windowsom expanziu neriesi shell ale kazdy program osve) a v adresary neexistuje nic ine, co by vzorke vyhovovalo.
-
Lael Ophir (neregistrovaný)
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.
-
Sten (neregistrovaný)
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.
-
Vite, oni delaji specialni filemanagery pro vas, aby vyhovovaly vasim predstavam. Obsahuji zpomalovatka a dalsi kurvitka, aby vam otevreni /etc trvalo nekolik vterin. Ja treba v mc cekat nemusim. Dlouho trva akorat velky adresar v ~/Private, za coz muze sifrovani obsahu vcetne jmen adresaru a souboru.
-
Lael Ophir (neregistrovaný)
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 -
Lael Ophir (neregistrovaný)
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/ -
Lael Ophir (neregistrovaný)
Nikdo vás nenutí. Pokud nepotřebujete číst nastupující primární formát karet SDXC, Memory Stick XC a USB klíčenek, nic vás nenutí. Můžete si pro to jedno procento uživatelů klidně udělat deset různých FS, které nepřečte zbylých 99% uživatelů, a nejspíš ani velká část z toho procenta linuxáků.
http://kb.sandisk.com/app/answers/detail/a_id/4396/~/formatting-a-64gb-flash-drive%2Fremovable-disk-on-windows-xp -
Lael Ophir (neregistrovaný)
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.
-
Tj jedna moznost. Ta druha, o dost pravdepodobnejsia je, ze sa karty, ktore nieje mozne precitat v ziadnom prehravaci, prenosnom zariadeni ani telefone proste predavat nebudu. Nebolo by to zrovna po prvy krat :)
MS nam so svojim FAT zavaril pekelne a zbavime sa ho az nejakym zazrakom. Suborovy system pre pamatove karty, ktory neprecitaju zariadenia pracujuce s pamatovymi kartami ma asi take sance, ako W8 na tabletoch :)
-
Lael Ophir (neregistrovaný)
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ě?
-
atos (neregistrovaný)
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)
-
Lael Ophir (neregistrovaný)
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í.
-
exFAT neni soucasti zadnyho Servise Packu. exFAT je samostatnej update http://support.microsoft.com/?kbid=955704
Zalezi jakej uzivatel a zalezi na jaky pouziti. Nekdy nemas moznost vyberu (treba nutnost pouzit ext2/3 na starsich verzich Androidu pro instalaci aplikaci na pametovou kartu), nekdy si muze vybrat podle moznosti FS nebo nalady...
-
Nechapu proc se tolik rozcilujete. Vlastni filesystem si zkousela napsat spousta studentu a hobbyistu. Ja mam taky svuj MySQLfs ktery je sice v praxi k nicemu ale byla to dobra zabava. No tak tenhle clovek si napsal filesystem jako diplomku a zverejnil patch. Ja taky na web davam svoje veci ktere mi pripadaji zajimave i kdyz necekam ze by je nekdy nekdo vyuzil (a kupodivu obcas nekomu pomuzou). Tak ho nechte zit ;)
