obmedzenia filesystemu UFS2: Too many links

[Lubomir Host]

On Mon, Jan 15, 2007 at 12:50:52PM +0100, Dan Lukes wrote:
> Lubomir Host wrote:
> > 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?
> 
> 	Vetsina z nicvh jsou pseudosystemy nebo vzdalene systemy. NTFS je, 
> pokud vim, read-only. Zbyva hpfs a msdosfs. O prvnim envim dost abych to 
> posoudil, druhy je pro praci s takhle velkymi adresari nevhodny.
> 
> 	Podle me zadny vhodny system v seznamu neni.

Hmm, no to je blbe. Malo by sa s tym nieco robit. Snad sa situacia vo
FreeBSD zmeni k lepsiemu, ked sa podari preportovat XFS a ZFS.

> > 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
> 
> 	To je skutecne tezke porovnat, navic, pokus o takove porovnani smrdi 
> flamewar. Nevim, jak je to v pripade UFS, ale v pripade EXT2FS byvalo 
> defaultni nastaveni takove, ze preferovalo vykon za cenu vyssiho havarie 
> filesystemu pri padu stroje (treba vypadku napajeni), zatinco an FreeBSD 
> bylo defaultni nastaveni (u UFS) opacne. Takze pripadne pokusy o 
> porovnani by bud' musely byt zalozeny na pomerne hluboke analyze, nebo 
> je treba je pojmout jako "proste porovnani dvou cisel bez znalosti 
> souvislosti"

Presne tak som to napisal: "... zdal 2x rychlejsi ...". Myslim, ze
nijako inac sa to pochopit nedalo. Zamerne som neuviedol ziadne dalsie
detaily (typ diskov, verzie OS, konfiguracia a pod.), aby sa to nedalo
chapat ako benchmark. Verim tomu, ze niekomu by sa podaril presne opacny
vysledok. Viem aj dat tip: porovnat rychlost mazania na linuxovom XFS
a lubovolnom inom operacnom systeme s lubovolnym inym filesystemom.
Mazanie na XFS je naozaj pomale. Nastastie to v ostrej prevadzke az tak
nevadi, pretoze sa castejsie subory hladaju podla cesty, ako mazu.

> 	To je v poradku, jen v tech funkcich, ktere finalne se souborem pracuji 
> je proste potreba pridat mezi druhy a treti znak jmena (a pripadne jeste 
> mezi ctvrty a paty) lomitko ...
> 
> 	Predpokladam, ze jsou tam tri funkce - vytvoreni obrazku, otevreni pro 
> cteni a smazani - takze je to celkem trivialni uprava techto tri funkci. 
> Nicmene, takovahle rada uz presahuej ramec teto konference.

Tych funkcii je tam asi trosku viacej, pretoze to v skutocnosti nie je
len taka obycajna databaza obrazkov. Zjednodusil som to, lebo sa jedna
o uzavretu aplikaciu a nechcem blizsie specifikovat jej funkciu.
V ostrej prevadzke je uz cca 3 roky. Tym, ze sme viac ako 100 tisic
suborov v jednom adresari pred cca rokom rozhodili do podadresarov podla
ID bol v zasade prinos, pretoze niektore funkcie sa zjednodusili. Akurat
nas vtedy nenapadlo otestovat limit na pocet podadresarov a v tuto dobu
to zacalo siahat ku kritickej hranici.

Kazdopadne dik za rady.

rajo

-- 
  ,''`.  Lubomir Host 'rajo' <rajo AT platon.sk>    ICQ #:  257322664
 : :' :  Jabber: rajo AT jabber.platon.sk      VoIP: callto://rajo207
 `. `'   WWW: http://rajo.platon.sk/  Platon Group: http://platon.sk/
   `-    GnuPG key: DC0C C7EA 55C8 B089 C41D 944A F251 A93A 2361 A82F