Fórum Root.cz
Hlavní témata => Software => Téma založeno: Jakub Váňa 20. 05. 2012, 21:41:05
-
Pěkný den,
nevíte někdo - potřeboval bych (spíš pro inspiraci při vývoji) "souborový systém", který rozdělí disk na bloky stejné velikosti - co blok, to soubor ?
Je někde něco takového ?
Děkuju
-
Samozřejmě je něco takového možné, ale co od toho očekáváš? Obvykle si pro podobné účely vystačím s nějakou databází.
-
Na to se bude dělat ještě přesná analýza - teď bych potřeboval mít v ruce nějakou implementaci pro demonstraci myšlenky.
V podstatě zatim stačí rozsekat disk na bloky a názvy souboru nahradit číslem tohodle bloku. Ani nepotřebuju direktorky.
Koukám tu teď do zdrojáků bfs a připadá mi to pro inspiraci ještě pořád moc složitý - i když asi se tim nějak prohrabu :D
Myslel jsem, že kdyby věděl někdo ještě o něčem jednodušším, že by mi to mohlo pomoct.
-
Našel jsem něco takového v Tokyo Cabinetu - formát TCF. Jenom nevím, jestli se to k tomuto účelu bude hodit.
-
No, já potřebuju opravdu souborový systém.
Cílem je maximalizovat výkonnost jedné specifické aplikace - k tomu potřebuju obejít různé nesmyslné algoritmy alokací bloků, tvorby inod atp.
-
A co takhle použít přímo diskový oddíl?
-
To už je asi zase moc low-level :D
Ale tak ten FS se napsat dá - jen, kdyby člověk viděl nebo vycházel z něčeho podobnýho, šlo by to rychlejc. ;-)
-
To už je asi zase moc low-level :D
Ale tak ten FS se napsat dá - jen, kdyby člověk viděl nebo vycházel z něčeho podobnýho, šlo by to rychlejc. ;-)
Já bych neřekl, že je to low-level. Pokud si otevřeš partition normálně přes fopen, tak s ní můžeš pracovat normálně
jako s velkým binárním souborem (pokud si do ní nastavíš právo pro zápis). (viz např. http://www.linuxforums.org/forum/programming-scripting/185467-using-fopen-fread-dev-sda.html). Pokud potřebuješ skladiště souborů/dat bez adesářové struktury, tak ti stačí v programu vytvořit tabulku (pole struktur v C/C++) kde budeš mít číslo bloku + popis/identifikaci souboru. Potom fseekem se přesuneš na adresu cislo_bloku * velikost_bloku a čteš/zapisuješ. Pokud potřebuješ i adresáře, tak ti stačí do tabulky přilepit ještě příznak adesáře a odkaz na podřízenou položku v tabulce. Tady už si musíš napsat funkce na čteni a zápis, které budou provazovat jednotlivé položky tabulky. Jestliže je požadována i perzistentnost, tak jednoduše tabulku zapíšeš do souboru a zase načteš. Podle mne nic rychlejšího (a pavděpodobně ani jednoduššího) nevymyslíš...
-
pro inspiraci muze poslouzit http://en.wikipedia.org/wiki/Google_File_System
-
To už je asi zase moc low-level :D
Ale tak ten FS se napsat dá - jen, kdyby člověk viděl nebo vycházel z něčeho podobnýho, šlo by to rychlejc. ;-)
Já bych neřekl, že je to low-level. Pokud si otevřeš partition normálně přes fopen, tak s ní můžeš pracovat normálně
jako s velkým binárním souborem (pokud si do ní nastavíš právo pro zápis). (viz např. http://www.linuxforums.org/forum/programming-scripting/185467-using-fopen-fread-dev-sda.html). Pokud potřebuješ skladiště souborů/dat bez adesářové struktury, tak ti stačí v programu vytvořit tabulku (pole struktur v C/C++) kde budeš mít číslo bloku + popis/identifikaci souboru. Potom fseekem se přesuneš na adresu cislo_bloku * velikost_bloku a čteš/zapisuješ. Pokud potřebuješ i adresáře, tak ti stačí do tabulky přilepit ještě příznak adesáře a odkaz na podřízenou položku v tabulce. Tady už si musíš napsat funkce na čteni a zápis, které budou provazovat jednotlivé položky tabulky. Jestliže je požadována i perzistentnost, tak jednoduše tabulku zapíšeš do souboru a zase načteš. Podle mne nic rychlejšího (a pavděpodobně ani jednoduššího) nevymyslíš...
Oprava - má tam samozřejmě být odkaz na nadřízenou položku :)
-
Oprava - má tam samozřejmě být odkaz na nadřízenou položku :)
A taky seznam podřízených položek, ne? Jinak by se potomek musel hledat sekvenčně... :)
-
Díky za tipy. Zkusím se ještě zamysled nad tím přímým přístupem do partitiony - možná, že by to přecejen mohlo být řešení.
-
Tim primym pristupem na partition jsi mi pripomel Sybase. Ta to tak dela strasne dlouho. Dokonce se tam da obejit i buffering u os. MySQL uz to taky umi. Tak proc vynalezat kolo;)
Pokud planujes nejaky storage filesystem pro SAN tak by to treba i smysl melo. Na druhou stranu pokud potrebujes adresovat blok po bloku a psat blok po bloku tak potes kokes. Uvedomujes si ze blok muze byt ruzne velky? Ze na druhe strane nemusi byt ani fyzicky disk? Jak se s tim poperes?
I pokud pouzijes fread, coz je porad buffered tak pro disky je nejlepsi precist/zapsat hromadu dat a ne jeden blok. Optimalni chunk dat k precteni si zjistis benchmarkem.
Naimplementovat filesystem neni sranda. Podivej jak dlouho se patlaji s btrfs.
-
Tim primym pristupem na partition jsi mi pripomel Sybase. Ta to tak dela strasne dlouho. Dokonce se tam da obejit i buffering u os. MySQL uz to taky umi. Tak proc vynalezat kolo;)
Pokud planujes nejaky storage filesystem pro SAN tak by to treba i smysl melo. Na druhou stranu pokud potrebujes adresovat blok po bloku a psat blok po bloku tak potes kokes. Uvedomujes si ze blok muze byt ruzne velky? Ze na druhe strane nemusi byt ani fyzicky disk? Jak se s tim poperes?
I pokud pouzijes fread, coz je porad buffered tak pro disky je nejlepsi precist/zapsat hromadu dat a ne jeden blok. Optimalni chunk dat k precteni si zjistis benchmarkem.
Naimplementovat filesystem neni sranda. Podivej jak dlouho se patlaji s btrfs.
Asi to opravdu bude varianta, ten přímý přístup.
Psát blok po bloku prostě v této aplikaci dává smysl i s rizikem, že tam občas vzniknou díry. Fyzický disk na konci vždycky bude.
Jeden blok je hromada dat :D Ty bloky budou opravdu veliké 16M ? 64M ? - něco takového:D
Btrfs - to je evidentně o dva až tři řády složitější záležitost, než potřebuju. Ve srovnání s tím, co potřebuju je složitý i bfs se svými 1158 řádky zdrojáků.
-
Tim primym pristupem na partition jsi mi pripomel Sybase. Ta to tak dela strasne dlouho. Dokonce se tam da obejit i buffering u os. MySQL uz to taky umi. Tak proc vynalezat kolo;)
Pokud planujes nejaky storage filesystem pro SAN tak by to treba i smysl melo. Na druhou stranu pokud potrebujes adresovat blok po bloku a psat blok po bloku tak potes kokes. Uvedomujes si ze blok muze byt ruzne velky? Ze na druhe strane nemusi byt ani fyzicky disk? Jak se s tim poperes?
I pokud pouzijes fread, coz je porad buffered tak pro disky je nejlepsi precist/zapsat hromadu dat a ne jeden blok. Optimalni chunk dat k precteni si zjistis benchmarkem.
Naimplementovat filesystem neni sranda. Podivej jak dlouho se patlaji s btrfs.
Asi to opravdu bude varianta, ten přímý přístup.
Psát blok po bloku prostě v této aplikaci dává smysl i s rizikem, že tam občas vzniknou díry. Fyzický disk na konci vždycky bude.
Jeden blok je hromada dat :D Ty bloky budou opravdu veliké 16M ? 64M ? - něco takového:D
Btrfs - to je evidentně o dva až tři řády složitější záležitost, než potřebuju. Ve srovnání s tím, co potřebuju je složitý i bfs se svými 1158 řádky zdrojáků.
No z toho prispevku mi pripadalo ze myslis diskove bloky jako 512 nebo 4096b i vic. Tam by samozrejmne sel vykon na tlamu. Chtel
jsem rici ze pro disk je lepsi kdyz popadnes hromadu tehle bloku. Bohuzel nevim o jakou aplikaci se jedna, tak tezko soudit. Pane Smrtka nemuzete aspon naznacit?
Diry jsou i na zcela plnem disku by design ale ty je nevidis. Jak se bude chovat disk jses dnes uz tezko jako uzivatel schopen odhadnout. Chce to zkouseni,benchmarky a uzkou spolupraci s vyrobcem.
-
No, já potřebuju opravdu souborový systém.
Cílem je maximalizovat výkonnost jedné specifické aplikace - k tomu potřebuju obejít různé nesmyslné algoritmy alokací bloků, tvorby inod atp.
Nejmenuje se náhodou ta „specifická aplikace“ po jednom mořském hlavonožci? ;) Ta prý nějak umí, že jí ty soubory prostě za sebou nacpeš na harddisk a ona si vyrobí index, natáhne si ho do RAM a pak už si v tom seekuje sama.
Jinak bych to vyřešil LVMkem - oddíly by byla LVčka, pokud je těch bloků do stovky (což, pokud máme na mysli tu stejnou aplikaci, tak je).
-
No, já potřebuju opravdu souborový systém.
Cílem je maximalizovat výkonnost jedné specifické aplikace - k tomu potřebuju obejít různé nesmyslné algoritmy alokací bloků, tvorby inod atp.
Nejmenuje se náhodou ta „specifická aplikace“ po jednom mořském hlavonožci? ;) Ta prý nějak umí, že jí ty soubory prostě za sebou nacpeš na harddisk a ona si vyrobí index, natáhne si ho do RAM a pak už si v tom seekuje sama.
Jinak bych to vyřešil LVMkem - oddíly by byla LVčka, pokud je těch bloků do stovky (což, pokud máme na mysli tu stejnou aplikaci, tak je).
Tak beru zpět, všiml jsem si, že „opravdu velikými bloky“ se myslí 64 MB. Hlavonožec je má velké 40 GB.
-
Je to něco, co vyvijim. bohužel jsem ale pod NDAčkem, takže zatím o tom nemužu mluvit.
A 40GB by se později možná špatně mmapovalo :D
-
Je to něco, co vyvijim. bohužel jsem ale pod NDAčkem, takže zatím o tom nemužu mluvit.
A 40GB by se později možná špatně mmapovalo :D
)
Pri dnesnich cenach je 40GB nic.
viz.MAP_HUGETLB
Mame tu naky aplikace ktery mapuji tyhle obrovsky pameti. A stranka je velka 1-2GB.
-
To je polovina celýho adresovýho prostoru :D :D :D
-
To je polovina celýho adresovýho prostoru :D :D :D
Tak mozna nejaky 32bitovy x86 kalkulacky bez PAE. Uz i x86 umi 1GB stranky.
-
Je to uplně jiná architektura, ale to je jedno ;-)
PAE řeší otázku, jak zpřístupnit fyzickou paměť. Pomocí PAE nezvětšíte adesový prostor.
-
Je to uplně jiná architektura, ale to je jedno ;-)
PAE řeší otázku, jak zpřístupnit fyzickou paměť. Pomocí PAE nezvětšíte adesový prostor.
Mas na mysli omezeni 4GB per proce? Jo to je vlastne pravda. Sice to lze obejit vice procesy, ale ta prace za to nestoji. Zelezo je za hubicku proti cene za vyvoj.
No ja tyhle fekalie typu PAE stejne rezolutne odmitam. Taky jsem to dal manazerum pekne vyzrat kdyz nekdo z nich kdysi "rozhodl" a mila java chtela po par letech vic jak ty 4GB. Pritom stacilo nainstalovat 64bit os a 64bit JVM a bylo.
Je fakt ze od te doby co jsem blize v kontaktu s jinymi architekturami, tak mne naka pametova omezeni netrapi.
Ba co vic. Vzdycky se divim co jsou schopni vyrobci na x86 zmotat ze tam nejde narvat vic pameti (byt teoreticky to mozne je).
-
Kde vzít výkon a nekrást.
Inu, jednak se to chce vykašlat na Javu i moje oblíbené C#.
Ani tak nemluvím o ztrátě výkonu při převodu bytecode na native, ale o podivném chování na tom kterém VM.
Pokud to má být aplikačka, za kterou bude někdo ručit, vyhnul bych se psaní vlastního souborového systému a všemu, co může někdy v budoucnu dělat bordel.
Dále, pokud jde o výkon, pak se vyplatí zátěž rozprostřít na víc disků.
Moderní disky mají NCQ, ale hlavně, SSD disk 120GB SSD stojí 3000,- Kč.
S SSD diskem pak ztrácí přímý přístup na partition smysl úplně, prostě je to kravina největšího řádu.
Buď se data na SSD vejdou a pak je to turbokravina, nebo se tam vejdou alespoň všechny indexy a operační prostor.
Můžeš vzít například 2TB disk a naházet si tam 64MB bloky, práce probíhá tak, že se pracovní bloky (které se řekněme nevejdou do RAM) nejprve přenesou na SSD a zapisuješ je na pevný disk.
Moderní pevný disk má rychlost zápisu cca 100~200 megabajtů /s kontinuálního streamu, ale jen 1/10 v případě rychlého střídavého načítání a zápisu.
Nejeden výrobce databáze kdysi vymejšlel úplně stejný hovadiny jako ty, Oracle s armádou programátorů to dotáhl až tak daleko, že jim to docela fungovalo, ale optimální to stejně nebylo. Takže nakonec přišli na to, že bude lepší použít stávající FS.
Jak říkám, buď rovnou použij SSD nebo SSD jako cache.
-
Možná původní požadavek nejlépe vyřeší Ext4 se zapnutým extents.
-
Kde vzít výkon a nekrást.
Inu, jednak se to chce vykašlat na Javu i moje oblíbené C#.
Ani tak nemluvím o ztrátě výkonu při převodu bytecode na native, ale o podivném chování na tom kterém VM.
Pokud to má být aplikačka, za kterou bude někdo ručit, vyhnul bych se psaní vlastního souborového systému a všemu, co může někdy v budoucnu dělat bordel.
Dále, pokud jde o výkon, pak se vyplatí zátěž rozprostřít na víc disků.
Moderní disky mají NCQ, ale hlavně, SSD disk 120GB SSD stojí 3000,- Kč.
S SSD diskem pak ztrácí přímý přístup na partition smysl úplně, prostě je to kravina největšího řádu.
Buď se data na SSD vejdou a pak je to turbokravina, nebo se tam vejdou alespoň všechny indexy a operační prostor.
Můžeš vzít například 2TB disk a naházet si tam 64MB bloky, práce probíhá tak, že se pracovní bloky (které se řekněme nevejdou do RAM) nejprve přenesou na SSD a zapisuješ je na pevný disk.
Moderní pevný disk má rychlost zápisu cca 100~200 megabajtů /s kontinuálního streamu, ale jen 1/10 v případě rychlého střídavého načítání a zápisu.
Nejeden výrobce databáze kdysi vymejšlel úplně stejný hovadiny jako ty, Oracle s armádou programátorů to dotáhl až tak daleko, že jim to docela fungovalo, ale optimální to stejně nebylo. Takže nakonec přišli na to, že bude lepší použít stávající FS.
Jak říkám, buď rovnou použij SSD nebo SSD jako cache.
Mimochodem Oracle treba doporucuje indexy na SSD uplne vypnout.
Nejeden vyrobce prisel na to ze je lepsi obejit FS uplne. Filesystem je urcita rezie ktera pri malem loadu muze byt nepodstatna, ale pri velke zatezi a slozitejsich filesystemech uz je problem. Hlavne je pak potiz odhalit kde se deje to zpomaleni protoze fs neni tak blby jako FAT32 ale je slozity.
Filesystem je specialni databaze a databaze neni nic jineho nez specialni fs. Tak proc mit databazi na databazi?
Napriklad specialne pro urcite filesystemy se i databaze optimalizuji. Zrovna Sybase musela byt specialne upravena pro ZFS a stejne tam meli bugu.
Muj osobni nazor je pro vykonove kriticke aplikace rict databazi kde ma SSD, kde ma pomaly disk a o ostatni at se postara sama. A pokud se jedna o casove casove kriticky narocnou vec tak este 256GB ram a vys, protoze i SSD dokazi byt pomaly.