Jaderné noviny – 27. 3. 2014: Velké disky a 32bitové systémy (diskuse)

[mmmm]

Možná už se to tu někdy řešilo, ale proč jsou tyto články publikovány s tak velkým zpožděním oproti originálům. Přesto díky.

[anonym]

A) preklad neco trva

B) pristup k aktualnimu LWN je placeny, archiv davaji zdarma

[registrovaný]

Jemonže překlad trval skoro dva týdny od uvolnění v archivu.

Takže si, anonyme, tazateli vůbec nic nevysvětlil.

[2X4B-523P]

je to hlavně pro neanglicky mluvící a líné uživatele... admini, kteří pravidelně aktualizují si čtou změny přímo a zavčas...

[registrovaný]

Ale stejně ty překlady trvají neskutečně dlouho.

[pavlix]

A?

[nnnn]

Hurá, náš malý Pavlix se dnes ve školce naučil písmeno A a otazník !

[R]

Ak sa ti nepaci, mozes robit preklady rychlejsie.

[Saljack]

Myslím, že žádný problém neexistuje. Proč by někdo chtěl používat 32bitový systém s tak velkým diskem?

[R]

Pretoze ma zariadenie s 32-bitovym CPU a potrebuje skopirovat nejake data z 16TB disku, ktore sa mozno coskoro budu predavat s USB rozhranim?

[Jendа]

Protože je embedded 32b SoC šíleně levný a málo žere.

[Milan Roubal]

Kde presne lezi to omezeni? Mam system Synology DS413j, procesor Marvell Kirkwood mv6282 armv5te, coz je podle vseho 32bitovy system a uvazuji o update disku v tomto roce. Jsou tu 3 varianty:

1. 4x 4TB disk - pri RAID5 a ext4 by nemel byt zadny problem
2. 4x 5TB disk - pri RAID5 ma disk 15TB, tedy s ext4 to bude fungovat?
3. 4x 6TB disk - pri RAID5 ma disk 18TB, tedy bude s tim problem? Pokud ano, bude fungovat 2x RAID5, jeden s velikosti 16 TB a druhy 2 TB?

[MalyZelenyHnus]

Problem je v jakemkoliv blokovem zarizeni >16TiB. (Testovano shodou okolnosti na jadre 2.6.31, Marvell Feroceon 6282): 1) zadny problem 2) zadny problem (vsechna blokova zarizeni <16TiB) 3) jo, to je problem. Ext4 ma rozumne nastroje, ktere ti a) zabrani vytvoreni fs, ktery neni mozne adresovat 32 bity, b) pri pouziti 64bit rozsireni ext4 to na 32bitu sice naformatujes, ale nejde primountovat. MDRAID je jeste veselejsi - dovoli ti pole vytvorit i sestavit a tvari se korektne. Ale kdyz jsem tam zapisoval pomoci dd, po chvili se zapisovana data zacala proste ztracet (tj. write() tvrdil ze zapsal, na disky se skrz mdraid vrstvu nic nedostalo).

Dve samostatna pole 16TiB a 2TiB fungovat budou, dokonce muzes udelat na discich dve partysny a do jednoho pole dat prvni partysny, do druheho zbyle. Tusim ze neco podobneho pouziva i QNAP.

[j]

Ja bych dokonce rek, ze lze i varianta dat to vse do jednoho raidu ... a rozdelit to na vic partysen. A dokonce by to pak mozna slo sfouknout tak, ze se to pro system bude jevit jako vic mensich disku, ale navenek jako jeden velkej.

Ale takovou R5tku bych nechtel prepocitavat ani na HW raidu, natoz na SW.

[MalyZelenyHnus]

Samozrejme, jeden velky raid + partysny na nem nepomuze, zase by tam bylo zarizeni >16TB.

Ja jsem navrhoval nejdriv udelat partysny na discich a nad partysnama udelat vice RAIDovych poli. Oproti reseni "dva disky pro jedno pole, dva disky pro druhe" to nezmensi pocet zarizeni v poli, takze se muze pouzit i raid5/6/10, ktere pozaduji vic disku.

Jeste jsem delal pokusy s aufs, ale pro ten stary (2.6.31) kernel to melo nejake bugy. Aufs (a existuje vic podobnych filesystemu) je filesystem, ktery nepracuje nad jednim blokovym zarizenim, ale nad nekolika a rozhazuje mezi nimi soubory podle ruznych nastaveni. Nevytvari teda velke blokove zarizeni, ale presto poskytuje sluzby jednoho souboroveho systemu. Takze komu staci jeden velky filesystem, muze vzit dve nebo vic disku (raidu) <16TB a vytvorit na nem jeden fs takhle. Zkusenosti s provozem ale nemam a moc bych tomu neveril.

[Kvakor]

Ještě je tu možnost použit distribuovaný souborový systém, i když poběží na jediném stroji. Celková velikost klidně může být >16TB, stačí jen aby jednotlivá zařízení byla menší. Nevýhodou by byl poněku nižší výkon, ale pokud se opravdu jedná o něco na způsob NAS, tak to pravděpodobně nebude zas tak velký problém (protože úzké hrdlo bude ve většině případů síť). Možná by dokonce stačilo použít jen "RAID" vlastnosti Btrfs (rozložení přes víc blokových zařízení), ale nejsem si jistý, jak přesně je to řešeno uvnitř.

[Milan Roubal]

Presne tak jsem to myslel, udelat nekolik poli pres 4 disky vzdy nad partition. Prepocitavani RAIDu se nebojim, s tim spatne zkusenosti nemam, spise se bojim e2fsck nad jednim velkym diskem, protoze ta masina na to nema dost pameti.

[Kvakor]

To jde obejít tak, že se buď celý souborový systém (nebo jednolivé oddíly) vyexportuje jako blokové zařízení (NBD nebo iSCSI) a zfscká se ze stroje, který má paměti dost. Jen to bude nejspíš trvat pekelně dlouho ...

[Honz]

Cachí je krásné slovo...

[Gilhad]

se zaměřila na řasu problémů zní taky půvabně :)