obmedzenia filesystemu UFS2: Too many links

[martinko]

Lubomir Host wrote:
> On Mon, Jan 15, 2007 at 11:27:40AM +0100, Dan Lukes wrote:
>> Lubomir Host napsal/wrote, On 01/15/07 10:35:
>>> chcem sa spytat, ci je mozne na nejakej verzii FreeBSD s nejakym
>>> suborovym systemom (napr UFS alebo UFS2) mat v jednom adresari viac ako
>>> 32766 podadresarov. Inymi slovami, aby presiel tento test (benchmark):
>> 	Aniz bych nahledl do zdrojaku, odhaduji, ze limit je ve skutecnosti 
>> limitem postu jmen, ktere muze nejaky konkretni inode mit. Adresar ma 
>> vzdy nejmene dve jmena (jmeno v nadrazenem adresaru a '.' v sobe samem) 
>> a kazdy podadresar k tomu prida dalsi jmeno ('..' v takovem 
>> podadresari), to je, u 32766 podaadresaru celkem 32768 jmen, coz by, 
>> pokdu se pocet linku uklada do dvou bajtu znamenkove byl presne nas limit.
>>
>> 	Jak jsem rikal, do zdrojaku jsme nekoukal, takze nevim, jestli se UFS2 
>> v tomto ohledu od UFS1 lisi. Pokud ani, tak pomuze prechod na UFS2, 
>> pokud nikoli, tak to samo o sobe resenim nebude.
>>> Dalsia podotazka: ako zistim, ze mam naozaj UFS2 a nie UFS? Vo vypise
>>> prikazu mount je stale napisane 'ufs', aj ked to je pravdepodobne UFS2.
>> 	dumpfs <device|moutpoint>
>>
>> 	Je to hned na prvnim radku.
>>
> 
> Skusal som to na roznych verziach FreeBSD. Na spominanej 6.0-RELEASE-p2
> mi dumpfs pise toto:
> 
> # dumpfs /home | head -n 1     
> magic   19540119 (UFS2) time    Mon Jan 15 11:48:14 2007
> 
> Na 4.11-RELEASE-p19 mi to zase pise:
> 
> # dumpfs /home | head -n 1 
> magic   11954   time    Mon Jan 15 11:52:14 2007
> 
> U mna test neprejde ani na jednej z tychto masin. Cize som si overil, ze mi
> prechod z UFS na UFS2 nepomoze.
> 
>>> Je tento problem riesitelny bez zmeny platformy?
>> 	Jak uz vyse padlo, mozna je a mozna neni resenim prechod na UFS2. 
>> Teoreticky moznym dalsim resenim je preklad worldu s predefinovanym 
>> typem pro ukadani teto polozky an neco vetsiho. Jednak je potreba (pote) 
>> preformatovat disk, jednak je i jakekoliv dalsi programu treba prelozit 
>> na takto upravenem stroji, ale ani to zdaleka nezarucuje, ze nebudou 
>> zadne problemy.
> 
> Takuto zmenu si fakt netrufam spravit a uz vobec nie nasadit len tak do
> produkcie. Taketo riesenie by bolo najskor neudrziavatelne do buducna.
> 
> Zdrojaky k UFS som nasiel v /usr/src/sys/ufs/, zatial co ostatne
> podporovane filesystemy som nasiel v /usr/src/sys/fs/. Prijde mi to
> trochu zmatocne, kedze to sluzi na to iste. V /usr/src/sys/fs vidim
> tieto filesystemy:
> 
> deadfs devfs fdescfs fifofs hpfs msdosfs ntfs nullfs nwfs portalfs
> procfs pseudofs smbfs udf umapfs unionfs
> 
> Ktore z nich by som teoreticky mohol pouzit ako nahradu za nativny UFS?
> 
>> 	Zmena platformy to vyresi po ujisteni se, ze na dane vybrane platforme 
>> je limit vyssi.
> 
> Linux 2.6.x jadro s XFS s vytvorenim 35000 adresarov (cize nad limitom
> FreeBSD s UFS1/UFS2) nemalo problem. Navyse sa mi ten moj jednoduchy
> benchmark zdal 2x rychlejsi na linuxe, aj ked je to tazko porovnavat
> (rychlejsie disky vo FreeBSD s ukoncenim na 32676 polozke, IDE disky
> v linuxe a koniec az na 35000 polozke).
> 
>> 	No a pak jeste muze reseni koukat ze strany, kterou je tezke posoudit, 
>> protoze vubec nevime PROC je potreba mit v adresari tolik podadresaru. 
>> Vetsina aplikaci, ktere znam ja, si existenci takovych limitu uvedomuji 
>> a maji pro tyto pripady nejaky mechanismus, ktery umoznuje data rozdelit 
>> do slozitejsi struktury s mensim poctem polozek v jednom adresari - 
>> treba vycleneneim nekolika prvnich znaku ze jmena pro prvni uroven 
>> vnoreni a ostatnich znaku nazvu pro dalsi uroven vnoreni adresaru (pocet 
>> urovni byva take nekdy konfigurovatelny).
>>
>> 	Samozrejme, pokud sama aplikace nepocita s tim, z eby byla nasazena pro 
>> "takhle velkou ulohu", nemusi to umet. Pak jeste muze byt resenim 
>> upravit aplikaci (stejne lze takove chovani povazovat za chybu navrhu) 
>> nebo s epodivat po nejake jine, ktera dela totez, ale je lepe napsana.
>>
>> 	Tezko ovsem posoudit, co muze byt resenim v tomto konkretnim pripade.
> 
> Aplikacia je v podstate frontend k databaze obrazkov. Na vyvoji
> aplikacie som sa podielaj aj ja. Priznavam sa. ;-)  Informacie
> o obrazkoch su ulozene v databaze, subory su na filesysteme. Kedze kazdy
> obrazok ma niekolko "podverzii", zdalo sa mi logicke zoskupit tieto
> verzie obrazkov do jedneho adresara a mena adresarov vytvarat podla ID
> zaznamu v databaze.
> 
> Ano, nevravim, ze sa to nedalo navrhnut inac, ale zial ma vtedy
> obmedzenie na pocet podadresarov nenapadlo testovat. Najma nie kvoli
> tomu, ze pocet suborov v jednom adresari vysoko prekracuje pocet 100
> tisic suborov.
> 
> Kedze znova upravit aplikaciu na pouzivanie viacerych urovni adresarov
> nie je prave najjednoduchsie a stary produkcny server aj tak treba
> upgradnut, vysledkom bude asi migracia na linux. Vlastne je aplikacia na
> linuxovom desktope dokonca vyvijana, takze by to nemalo byt
> komplikovane.
> 
> rajo
> 

skromne si myslim, ze rozumne napisana aplikacia by nemala byt problem
takto upravit.  dokonca aj tie id by ste mohli ponechat, akurat zanorit
adresare ako napisal dan.
okrem toho sa nazdavam, ze vo fs typu ffs je rozumnejsie to s poctom
podadresarov prilis neprehanat, aj keby tam bol teoreticky pocet vyssi
ako 32k.  (ale to sa naozaj len nazdavam, detaily si uz nepamatam.)

a pocet 100t suborov myslite v jednom adresari?  to sa mi zda hodne
prehnane.  je k tomu nejaky prakticky dovod?  bez ohladu na to kolko
suborov znesie v adresari (akykolvek) fs.

m.

ps: rychlost fs je relativna, resp. solidny benchmark je tazke spravit.
 ale na druhej strane pre vas ako uzivatela je podstatne ako sa to chova
vo vasom konkretnom pripade.