Příspěvky

226

Server / Re:Lokálny DNS server neforwarduje Gmail

« kdy: 26. 09. 2012, 15:32:36 »

Pokud potřebujete resolvovat neco.neco na vámi určenou adresu, tak si pro to na daném serveru zřiďte zónový soubor. Jinými slovy, postavte pro danou zónu autoritativní DNS server. Pokud se klient tohoto autoritativního serveru zeptá na nějaký záznam z domény neco.neco, dostane správnou odpověď.

Pokud současně chcete, aby tento server fungoval i jako resolver (což nedoporučuji, je lepší autoritativní a resolvující sever oddělit, případně je nutné ošetřit, aby resolvování bylo povolené pouze pro klienty vnitřní sítě), tak i tento může fungovat bez potřeby forwadovat požadavky kamokliv dále. Bind umí fungovat jako rekurzívní resolver sám o sobě. Mícháte 4 věci dohromady. Autoritativní server, resolver a rekurzivní resolver a ještě dnssec validator. Bez znalostí to opravdu nepůjde.

227

Hardware / Re:Jaký iSCSI Target pro Debian?

« kdy: 24. 09. 2012, 21:43:24 »

100MB/s? fuha, takovou dle rychlost jsem nedostal z 1Gb NI ani nahodou, max sem se priblizil k 70MB/s na linearnim cteni a 25MB/s na zapis(take linearni - dd) - to byl stgt

kousek vice jsme dostal na stejnem hw z iet - 90MB/s cteni a 35MB/s zapis

tehdy jsem to testoval na gentoo. Jako uloziste byl vzdy soubor(rozdil oproti lvcku ci primo disku byl minimalni - +-3MB/s).

A jinak ta sit beha normalne? FTP nebo netcat musi davat 100/100 (full duplex gigabit). Take jsem to ladil. Obcas je to pekne k zlosti, kdyz se pro sitovku za 8tis a v enterprise distru museji kompilovat drivery. Intelka se nam dokonce vypinala (coz je u file serveru ponekud nestastna featura) a pomohlo az update firmware. Jinde se museji vypnout vsechny setrici fce. S drivery primo od vyrobce (Intel, Realtek) to jde bez problemu. Smutne na tom je, ze ti vyrobci sice davaji drivery jako opensource, ale k tomu je binarni blob v podobe firmware, bez ktereho je ten hw jen nefukcni srot. Potom, kdyz uz sitovka jede, je spis problem, ze to dokaze ucpat levnejsi switche a latence jdou az na sekundy a jakekoliv rizeni io je pak na nic.

Co se tyce vypadku site, tak ten nas fileserver pro esx prezije i restart switche (par desitek sekund). Vmware to nepolozi, naopak se pripoji okamzite po obnoveni spojeni, ale pokud trva vypadek dlouho (radove minuty), tak se systemy souboru ve virtualkach prepnou do readonly rezimu. Doma na widlich se to chova v podstate stejne, pocka to, az se "disk" opet pripoji. Vim, ze to nejsou exaktni crash testy, ale v praxi jsem na poskozeni dat jeste nenarazil (a z hlediska navrhu fs by ani nastat nemel) a to uz to zazilo asi vsechny katastrofy.

228

Hardware / Re:Jaký iSCSI Target pro Debian?

« kdy: 24. 09. 2012, 16:57:58 »

Používáme na CentOS STGT (z repa). Rychlost je omezena pouze rychlostí sítě, u nás 100MB/s, bond jsme ještě nenastavovali. 100MB/s je pro nás bohatě dostačující, většina zápisů je stejně náhodná a ne sekvenční. Na strojích s UPS a redundantními zdroji jsme si troufli i na writeback nastavení cache pro target, rychlost je tak vynikající i pro spoustu drobných zápisů (16GB RAM jako cache se hodí a je to poznat). Tam je rychlost obvykle větší, než lokální disk. Podle dané tabulky by to měl být nejpomalejší driver, tak nevím.

Na Debianu je afaik IET a ten alespoň v mém testu (Debian Squeeze vs. Windows 7 jako iniciator) dokonale propadl. Možná je to rukama, ale každý zápis (to bych ještě chápal, i když na disk to má jít až po vyžádání flush cache) a čtení (tohle už ne) šlo přímo z disku, bez cache. Nepoužitelně pomalé.

229

Vývoj / Re:Škálovatelnost webové aplikace

« kdy: 24. 09. 2012, 13:25:20 »

Zřejmně je to dotaz v teoretické rovině. Tak proč nediskutovat.

Je třeba si uvědomit, co taková aplikace potřebuje. Pokud budu vycházet z klasické trojvrstvé struktury: persistentní úložitště (systém souborů, databáze), aplikační vrstva na serveru (PHP) a tenký klient (webový prohlížeč), tak:

Pokud nestíhá úložiště, je možné nastadit replikace dle typu zvoleného úložiště. SQL lze snadno replikovat jako master - slave. Dotazy mohou jít na farmu slavů, inserty na master. Nutná přestavba aplikace, pokud se s tím nepočítá přímo v návrhu. Některé KV DB umí i replikaci master-master, pochopitelně s omezením dle CAP. Storage vrstva se může také realizovat čistě jako distribuovanou memory DB (Redis) a persistenci řešit jinak (nebo nijak a spoléhat se jen na vzdálené lokality).

V případě souborů na disku existují clusterované systémy souborů (GlusterFS). Každá aplikace by měla mít přístup ke všem souborům. (Opět, jako u každé distribuované aplikace, je zde omezení dané CAP.)

Též je možné mezi storage a aplikaci nasadit cache (memcached). Nejrychlejší dotaz je takový, který se nemusí vykonat. Toto je asi nejčastější optimalizace na straně storage. Nějaká forma cache mezi diskem a aplikací.

Aplikace může běžet ve více instancích, pokud je zachována konzistence úložiště.

Před aplikacemi může běžet reverzní cachující proxy (squid, nginx). Což je nejčastější optimalizace mezi webovým serverem a webovým klientem. V případě více instancí aplikace lze před farmu aplikačních serverů nasadit také loadbalancer. V takovém případě může mít loadbalancer klidně jednu IP a za ním být spousta instanací aplikace. Loadbalancer může být také ve více instancích pro high avail.

Jinými slovy, pokud je zachována konzistence dat na straně storage, aplikace může běžet v mnoha instancích za jedním nebo více loadbalancerů.

230

Sítě / Re:IPv6 - Pověry a fakta

« kdy: 21. 09. 2012, 16:32:04 »

Dalším argumentem který se objevuje je otázka migrace adres, které se díky NATU dá realizovat, a ke kterému prý pro velké firmy není adekvátní náhrada v IPv6.. ale to je na další dlouhý flame, protože jedna strana tvrdí, že nástroje jsou a druhá, že nejsou "stejné" jako NAT. Nicméně vzhledem k změnám na síti při změně adres i toto beru jako možné bezpečnostní riziko vzhledem k lidskému faktoru.

Dělal jsem asi 3x přečíslování celé sítě včetně všech zákazníků u jednoho malého lokálního ISP a dvakrát na našem firemním hostingu s produkčními servery (a to včetně změny housingu). Změna adres přinese většinou daleko větší pořádek, protože se věci po létech udělají znovu a lépe a nastaví se to od nuly. Nebyl to žádný velký problém. Ale chápu, že přečíslování 10let staré sítě s několika tisíci hosty může být problém.

IPv6 má prostředky daleko silnější než je NAT. Chápu, že někdo může vidět eleganci v tom, že má tabulky se dvojicí vnitřní : vnější adresa (pro symetrický nat) a kteroukoliv stranu tak kdykoliv moci změnit bez dopadu na stranu druhou. V IPv6 se stejnou elegancí může mít každý host několik IPv6 adres z různých rozsahů, třeba pro různé účely. Pro přidělení další adresy do sítě stačí nastavit další RA. Takto lze například přeadresovat sít na jiný rozsah. Oznámí se nový router, zvýší se mu priorita, ohlásí se pomocí RA, hosté si automaticky změní default routu a aniž by to kdokoliv poznal (když se to udělá i se změnou DNS záznamů), během krátké chvíle mají všichni novou síť a novou gw. IPv6 má na tohle prostředky přímo, bez pomoci DHCP. Což by šlo použít samozřejmně též. Jinými slovy, pokud se používá RA a autokonfigurace, tak úplně stejně může existovat tabulka MAC - DNS záznam pro každého hosta přes všechny použité subnety. A kdykoliv to změnit. Je to něco jiného než symetrický nat, ale řeší to stejnou věc.

Když tak nad tím přemýšlím, tak si lidé asi zvykli na to, že tento konkrétní počítač má na věky věků adresu 192.168.0.1 a vše ostatní se "nějak" zařídí na routeru. IPv6 ale může být mnohem dynamičtější (privaci extension), host může mít každý den adresu z úplně jiného subnetu apod. Nic nového, u IPv4 to šlo také. Ale správci nejsou zvyklí pracovat se subnety (nikdy jich neměli dost na hraní), jen s jednotlivými adresami. Třeba se to změní.

231

Sítě / Re:IPv6 - Pověry a fakta

« kdy: 20. 09. 2012, 16:32:07 »

to firewall, Tomáš Crhonek, Miroslav Prýmek:
  IPv6 a služby v cloudu na vás..... Nezapomněli jste na téma?

Téma je o tvrzení "uživatel nepotřebuje žádný počet veřejných adres, protože mu stačí NAT" a že "NAT je lepší než neNAT".

Co takhle přirovnat NAT ke garáži a zamknuté auto k firewallu. Garáž odradí NÁHODNÉHO útočníka od cíle, protože neví co v té garáži je. Nicméně toho kdo chce ukrást Vaše auto to neodradí, jenom to znesnadní (stejně jako NAT). Lidé si v garáži auto často nezamikají, ale to nezmanená, že nezamčené auto nemá žádný význam. Oproti tomu zamčené auto je na parkovišti nutnost, byť to ne všechny zloděje odradí. Otázka je, jestli NAT lze dostatečně nahradit externím firewallem, který je součástí routeru (jako zamknout si auto za vratama na dvorku u baráku (vrata jsou tedy jako externí firewall)).

Prostě si myslím, že neNAT je vzhledem k možnostem a důsledkům PŘÍPUSTNÉ RIZIKO výměnou za globálně dostupnou adresu na PC (stejně jako zamčené auto na parkovišti, raději to, než 2 km od baráku garáž, navíc kdybych chtěl můžu kolem auta na parkovišti rozmístit senzory ). Ale chápu, že ne všichni budou souhlasit.

Proti mnoha argumentům lze oponovat, že domácím zařízením, které nechceme mít na netu stačí komunikovat pomocí LL adres. Ty zařízení které mají být přístupné přes Inet je třeba aby zabezpečil výrobce (aby rozlišoval domácí komunikaci od té z netu (to lze, například televize by mohla mít pro youtube komunikovat pakety s ttl 128, oproti tomu pro vzdálené ovládání by se musela použít menší hodnota TTL, autentizace, explicitní povolení uživatele lokálně, ssl atd... samozřejmě v kombinaci.)

Jo sorry, zpět do TopTopicu.

Přirovnání pokulhává. NAT (maškaráda) je jen překlad adres. Nic víc, nic méně. Bezpečnostní bariéra je nulová. Narozdíl od fyzické garáže. Pokud někdo chce skrýt interní implementaci, má k disposici proxy (afaik v OOP existuje návrhový vzor proxy přesně k tomuto účelu). Od bezpečnosti sítě je zde packetový filter, chcete-li firewall. Pojmy jako externí a interní firewall nechápu. Firewall prostě komunikaci propustí nebo ne, je jedno, kde je umístěn. Asi je tím myšlen fw umístěný na routeru (kde být může a nemusí) a přímo na síťovém hostu (kde být může a nemusí).

Bavit se o NATu a neNATU jako o přípustném riziku mi přijde takové... Prostě síť je o peer to peer komunikaci a Internet vznikl jako síť propojující sítě a přinesl tak možnost globální peer to peer komunikace (lokální tu byla od počátku). Bez ohledu na možnost si tu komunikaci filtrovat firewallem. To není popření globální komunikace.

Maškaráda vznikla mnohem později jako jedna z reakcí na docházející IPv4. Tím chci říct, že základ Internetu je v globálních routovacích adresách a tak prostě vznikl a funguje. IANA ani žádná jiná Internetová organizace maškarádu za připojení k internetu nikdy neuznala, protože technicky není (host za maškarádou je vyjmut z možnosti globální peer to peer komunikace). A trochu mě mrzí, že dneska je situace de fakto opačná, že se musí vysvětlovat, proč je potřeba mít globální adresu a mnoho lidí bere maškarádu jako default. Není a nikdy nebyl. Přináší to jen problémy, není to žádná bezpečnostní ani privátní bariéra.

Takže závěr. Globální routovaná adresa, ani IPv4 ani IPv6 není žádné ohrožení a žádné riziko. Je to naopak to, co je od počátku zcela integrální součástí sítě a je to to, co by každý síťový prvek měl mít by default. S bezpečností to nijak nesouvisí. S bezpečností souvísí to, jak jsou zabezpečené služby a jak jsou zabezpečené sítě.

232

Sítě / Re:IPv6 - Pověry a fakta

« kdy: 20. 09. 2012, 14:39:22 »

Ale u takového "kdokoliv" vím kdo to je - musím znát své uživatele. To je podstatný rozdíl proti útočníkovi který se mi dostal na server omylem, ale se kterým je nutno počítat - statisticky se to prostě jednou za čas stane, protože komplikovaný software bezpečnostní díry měl, má a bude mít.

Já tedy nevím, zda si rozumíme. Thread původně začal tím, že je třeba (podle vás) zabezpečit firewallem server tak, aby v případě jeho kompromitace (kompromitace jeho internetových služeb) stejně nemohl komunikovat.

Jenže co komukoliv brání si zřídit vlastní server (vpn, proxy relay, tor apod) a komunikovat z něj, bez složité kompromitace jiných služeb? Tam mířila moje námitka. Zkrátka jestliže budu skutečně chtít odstřelovat ostatní, tak mám asi tak mega jednodušších možností, než crackovat jiný server. Tím jako neříkám, že by tam ta obrana neměla být, ale jen je podle mě zbytečné bránit něčemu, co si dotyčný může udělat mnohem snadněji vedle. Taková obrana je zbytečná a komplikující. Nehledě na to, že i webové aplikace často potřebují komunikovat s venkem oboustraně.

233

Sítě / Re:IPv6 - Pověry a fakta

« kdy: 20. 09. 2012, 10:41:55 »

Z druhého bodu musí mít extrémní radost správci všech serverů na které bude kompromitovaný stroj útočit, protože útočník má neomezenou možnost síťové komunikace. Pro mě je takový přístup nepřijatelný.

Neomezenou možnost síťové komunikace má kdokoliv, nejen kompromitované stroje. To opravdu není moc dobrý argument.

234

Sítě / Re:IPv6 - Pověry a fakta

« kdy: 20. 09. 2012, 10:34:09 »

Takže mi tahle myšlenka přijde trochu jako zamykání branky, u které není plot

Souhlas. 

Jsou sítě, kde se omezuje provoz oboustraně, vyjmenovává se každá jednotlivá služba apod. Většinou to vypadá tak, jak jsem psal. Jsou povolené všechny služby, které na serveru běží a žádná jiná se na server stejně nedostane. Ale tak ok. Jsou i sítě, kdy komunikace (pouze http) dovnitř jde jen přes reverzní proxy a komunikace ven přes autentizaci na normální proxy. Pokud jsou na ostatních služby vnitřní servery, tak je do taky ještě docela ok, hlavně když to není tajná transparentní proxy. A pak když tam chcete pracovat, tak vám správce dá tajně přístup na "zadní vrátka" a dostanete se všude (i takový už jsem dostal). Výsledkem je extrémně drahé řešení, které, aby se tam dalo pracovat, tak tam někdo udělá díru. Jinak totiž pracovat nejde. Takže výsledkem je stav, na který je snad i nějaký audit a správce pro vlastní práci tam má někde soukromou VPN.

Teď pracujeme na projektu pro jeden z největších podniků v ČR. Všechno musí schvalovat bezpečnostní oddělení, všechno musí projít přes tamní správce sítě, vše je na příkaz a povolení od vedení a vše je pouze dočasné. Adresy DNS resolverů jsem dostal "už" po 14 dnech (forward před 16 lidí) a SMTP relay nastavovali bezmála měsíc. Jako dobře, možná že to je bezpečné, ale z tohoto způsobu práce je jasné, že tam nikdo nemá celkový přehled o celé síti (možná je to tak schválně). Povolují a zakazují se jen jednotlivé schválené služby a asi by šlo si nechat "nezávisle na sobě" povolit takové kombinace přístupů, že by z toho byla díra jak vrata do dvora. Výsledek je ale extrémně pomalé nasazení produktu, místo dvou dnů je to již na 3 měsíce. Na druhou stranu, je kompletně dokumentován každý krok a to je rozhodně plus. Ale nestěžuji si, na rozdíl od ostatních podniků, tady ti lidé dobře vědí co dělají a mají přehled o technologiích i mimo svůj obor. Jen by to chtělo větší systémovou flexibilitu.

235

Sítě / Re:IPv6 - Pověry a fakta

« kdy: 19. 09. 2012, 17:27:15 »

Ano, ostatní služby na serveru nemají co dělat. Ale co když se tam omylem dostanou? Typický příklad: děravý webserver (např. za pomoci PHP) umožní útočníkovi cosi spustit - a útočník zkusí buď odchozí síťové spojení, nebo naslouchat na nějakém portu. V tomto případě je firewall který tomu zabrání prostě nutnost.

Už přímo z tohoto komentáře je vidět, že problém je opět jinde. Na server se služba jen tak omylem nedostane. A pokud ano, tak se správci zruší pracovní smlouva (a to záměrně, ne omylem).

Děravý webserver je skoro totéž. Asi nechceme provozovat děravý webserver, že ano. Souhlasím, že zde firewall s nějakou detekcí může pomoci v nalezení problému. Ale nezabrání mu.

Nejsem proti firewallu, spravuji jich hodně, ale nesmí se brát jako první a hlavně ani jako jediná bariéra.

236

Sítě / Re:IPv6 - Pověry a fakta

« kdy: 19. 09. 2012, 14:59:55 »

Kapitán se koukám napil asi trochu metylu.

Porty otevírat nechce (to je riziko na které se okamžitě někdo přilepí), to by mě zajímalo, na co se vlastně připojuje na síti, když by všechny porty nejraději zavřel a všechny sítě schoval za maškarádu. Nejspíš nikam.

A teď trochu konstruktivnější odpověď. Síťové služby jsou přirozeně určené k tomu, aby se na ně někdo připojil. Tudíž je lze (resp. mají být nastavené s ohledem na bezpečnost) nastavit tak, aby byly bezpečné. Jestliže někdo provozuje OS, který je apriori nezabezpečený, tak mu nepomůže ani nat, ani fw. Není náhodou, že většina (skutečných) útoků pochází z LAN, která se bere jako bezpečná (stačí se dostat skulinkou do LAN a celá síť je vaše). Jinými slovy, problém je úplně jinde, než v NAT nebo FW. Velmi často poskytují jen pocit bezpečí.

Na svém serveru, světe div se, firewall nemám. Nemá totiž co filtrovat. Všechny služby jsou nutně dostupné z Internetu (od toho je to Internetový server) a tedy firewall by byl nastavený tak, aby propustil všechny naslouchající porty. Je tam prostě zbytečný. Ostatní služby na serveru stejně nemají co dělat.

Stejně jak v domácnosti. Většina klientských stanic žádné síťové služby (by default) neposkytuje. Dokonce tam často už není ani ssh. Takže stanice reaguje jen na ping. Naopak, každá síťová instalovaná služba, je instalována s cílem, že se na ní někdo připojí. Takže se v zápětí musí povolit ve FW nebo přidat port foward.

Navíc, lidé mají pocit, že je třeba vytvářet nějaké megahradby, fw, proxy apod. Opak je pravdou. Většinou ta nejjednodušší možnost je i ta nejbezpečnější. Vezměte si ssh. Vymýšejí se různé kraviny, jako změna portu, přejmenování roota, port knocking a já nevím co ještě. Jenže nakonec tohle všechno pouze zkomplikuje přístup na server tomu, kdo se tam dostat chce. A jsme na začátku, tak služba musí být dostupná a stejně je. Změna portu je pouze pocit, nikoliv bezpečnost.

Daleko nejlepší je použít přihlášení pomocí klíčů. RSA 2048b vám jen tak někdo necrackne. Rázem se přístup zjednodušší, bezpečnost se zvýší o několik řádů.

Viděl jsem servery, kde se provozuje FTP a protože je to "apriory nebezpečné" tak se vymýšlelo blokování ip po x pokusech apod. Většinou se takhle zablokoval ten, kdo tam něco chtěl dělat. Přitom je řešení triviální. FTP dát pryč a používat scp. S klíčema. Je to mnohem jednodušší a mnohem bezpečnější.

Takže tak. Viděl jsem mnoho sítí, které působily jako pevnost. Jenže jak jste jedou vevnitř, můžete cokoliv (i věci jako, přístup z LAN bez loginu apod). Je daleko lepší neoddělovat vnitřní a vnější síť a služby prostě nastavit pořádně. Místo login a heslo to může být právě SSL klíč. Používá se to pohodlně a ta služba se klidně může vystavit ven.

A jak to souvisí s IPv6? No prakticky nijak. IPv6 umožní si snadněji postavit sít, snadněji nastavit firewall a snadněji skrýt obsah sítě. Ale bezpečnost samotná na IP protokolu nezávisí.

237

Server / Re:návrh databáze - tabulky vs tabulka

« kdy: 05. 01. 2012, 13:28:13 »

Ahoj,

začínám dělat aplikaci a řeším problém s návrhem mysql databáze. snažím se přemýšlet trochu dopředu a tak myslím na budoucí výkon a zátěže

aplikace bude mít registrované uživatele

jde mi o to, jestli je lepší, v rámci výkonu a budoucí možné zátěže, udělat pro jednotlivé uživatele vlastní tabulky s jejich daty nebo všechno řešit na základě pár tabulek a z nich tahat data pro jednotlivé uživatele

díky za pomoc a sorry za trochu divný předmět tématu, nic lepšího mě nenapadlo:)

Nejlepší řešení bude to DB schéma navrhnout podle normálních forem (první až třetí stačí) a dle dotazů a výsledků příkazu explain potom navrhnout indexy. Takto navržené schéma bude daleko flexibilnější z hlediska dotazů a mnohonásobně rychlejší, než "intuitivní" návrh z hlavy.

Navíc v tom tvém návrhu by pro tisíc uživatelů muselo být vytvořeno tisíc tabulek. Tísíc otevřených souborů, tisíc položek v table cache. Už je to jasné? To nebude rychlé nikdy.

238

Distribuce / Re: CentOS vs. Scientific Linux

« kdy: 22. 07. 2011, 09:43:32 »

Scientific Linux robí dojem dosť minoritnej distribúcie.

SL je především výchozí platforma pro laboratoře CERNu a Fermilabu. Tedy, mají základní OS, kde mají společné nutné věci (jako OpenAFS, které například v CentOSu v základu není) a každá jednotlivá laboratoř si pro své účely dodá vlastní software a tím si vlastně vytvoří vlastní distro.

Toto asi obecnou veřejnost moc nezaujme.

Tedy SL vychází z RedHatu, ale SL nerovná se RH. Mají tam vlastní úpravy, bohužel vlastní chybu a nejsou (ani se o to nesnaží) být s RH binárně kompatibilní.

Cíle CentOSu jsou jiné, tam je snaha o 100% kompatibilitu s RedHatem. Proto také vydání 6.0 trvalo tak dlouho. v SL to vydali ve chvíli, kdy s tím byli sami spokojeni, zatímco v CentOS ve chvíli, kdy jim to prošlo testy.

239

Hardware / Re: Pomalý zápis malých souborů

« kdy: 16. 05. 2011, 21:55:01 »

Zdravím, uvažuju nad koupí SSD disku a tak koukám na testy. Zarazila mě jedna věc, řádově se liší rychlost sekvenčního čtení/zápisu od práce s malými (4kb) soubory. Sekvenčně dá disk třeba 250MB/s, ale s malými soubory jen 10MB/s. Proč to tak je? Jaký je rozdíl mezi zápisem jednoho velkého a stovky malých souborů?

Zápis malých souborů na SSD není pomalý, ale naopak, je relativně rychlý. Relativně vůči klasickému točivému disku. Zatímco u SSD jde práce s 4kB soubory rychlostí jako píšeš 10MB - 20MB/s (dle modelu), tak u HDD jsou to rychlosti v řádech 0.5MB/s. SSD je v práci s takto malými bloky až 40x rychlejší, než klasický disk.

Pomalejší zápis 4kB souborů oproti sekvenčnímu zápisu je dám mnoha faktory. Některé už popsal předřečník, já k tomu dodám také režii systému souborů, kdy pro každý zapisovaný soubor musí upravit adresářovou strukturu, tabulku inode, bitmapu volného místa a další metadata. To přidává další zápisy navíc.

240

Software / Re: Fsck (ext4) paměťové nároky

« kdy: 10. 05. 2011, 12:10:40 »

Možná by vás to mělo trknout a přivést k zamyšlení, zda je tento vysněný koncept ten správný. Na 30TB úložiště a 32b (3GB RAM), dost dobře nejde dohromady.

Na fsck jste narazil sám (u XFS by vám to neprošlo, i když tam by především neprošel ten 32b OS),  ext4 také potřebuje paměť pro buffery (inode, metadata) a ty se obejít nedají a v neposlední řadě by se tomu fileserveru pro běžný provoz hodilo i pěkných pár giga cache.