FS se stejnou velikostí souborů

[Jenda]

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).

[Reklama]

[Jenda]

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.

[Jakub Váňa]

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

[Trident]

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

)
Pri dnesnich cenach je 40GB nic.
viz.MAP_HUGETLB
Mame tu naky aplikace ktery mapuji tyhle obrovsky pameti. A stranka je velka 1-2GB.

[Jakub Váňa]

To je polovina celýho adresovýho prostoru

[Reklama]

[Trident]

To je polovina celýho adresovýho prostoru

Tak mozna nejaky 32bitovy x86 kalkulacky bez PAE. Uz i x86 umi 1GB stranky.

[Jakub Váňa]

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.

[Trident]

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).

[KapitánRUM]

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.

[Kit]

Možná původní požadavek nejlépe vyřeší Ext4 se zapnutým extents.

[Trident]

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.