[linux] Aky filesystem pouzit? (bolo: Rychlost software RAIDu na Debiane)

[Peter Viskup]

Ja rad pouzivam XFS na vsetky aplikacne data. Myslim, ze je to 
dostatocne skalovatelny filesystem a vhodny najma tam kde potrebujes 
paralelne pristupy - vid. "Allocation groups" [1]
Okrem ineho v pripade velkych FS ponuka rychly FS-consistency check, 
neviem nakolko je to lepsie v EXT4...mensou nevyhodou, ktoru som ja 
pocitil je, ze neponuka moznost jednoducheho a online zmensovania FS.

--
Peter

[1] http://en.wikipedia.org/wiki/XFS

On 01/27/2012 08:24 PM, Juraj Remenec wrote:
> Ja som uz asi pochopil o co ide.
> Ten proces, ktory spomaloval cely chod servera - zatial bezal len 
> jeden krat. Ked som vytvoril raidove pole. Je to nejaky Rebuild co sa 
> spustil a bezal niekolko minut, ked som na novo vytvoril raidove pole 
> a od vtedy som nepostrehol, ze by sa spustil znova. Uvidim ako sa to 
> bude chovat za ostrej prevadzky ale asi je to normalne. Ja zas az tak 
> do toho mirrorovania (Raid1) nevidim.
>
> Co sa chcem ale este spytat.
> Aky filesystem by ste pouzili na 1 TB SW-RAID1 pole pre /home particiu 
> na ktorej bude stovka-tisic malych suborov (Maildir + dovecot + 
> tisicka uzivatelov = mega po prdel fajlov!).
> Potrebujem mat rychly pristup k tymto suborom. No samozrejme nechcem 
> nijak extra vykonovo diskriminovat ani uzivatelov, ktori budu vo 
> svojom home pracovat s "gigovymi" subormi.
> Nejaky schopny kompromis. Dostupne moznosti: EXT3, EXT4, btrFS a XFS.
> Uz som si precital mnoho, mnoho pokecov a benchmarkov ale kazde sa 
> lisia. Zatial co jeden vynasa do nebies BtrFS, tak druhy zasa 
> preferuje ext4 a pod.
>
> Kedysika som ospevoval EXT3 v standard system konfiguracii ale v 
> urcitom momente sa na particiu nedal ulozit ziaden dalsi subor aj ked 
> na nej bolo miesto. Zistil som, ze su plne inodes a jediny sposob ako 
> to vyriesit bolo data-destruktivne tune2fs. Odvtedy pouzivam XFS ale 
> nemyslim si, ze je to to prave, orechove pre take mnozsto malych fajlikov.
>
> Aky na to mate nazor?
> J.
>
>
>
>
>
> 2012/1/23 Matus UHLAR - fantomas <uhlar at fantomas.sk 
> <mailto:uhlar at fantomas.sk>>
>
>         On 01/23/2012 09:32 AM, Matus UHLAR - fantomas wrote:
>
>             Pokial viem, v BIOSe je ulozeny aj softver toho RAIDU,
>             t.j. ide o sw RAID ulozeny v ROM/flash pamati, jednak
>             pomalsej ako RAM, jednak je ten SW RAID velmi
>             pravdepodobne nekompatibilny s inym HW, mozno aj verziami
>             BIOSu.
>
>
>     On 23.01.12 09:51, Peter Viskup wrote:
>
>         posli nejake info o tomto softveri RAIDu v BIOSe, pretoze
>         tohoto som si nie vedomy
>
>
>     wikipedia:
>
>     http://en.wikipedia.org/wiki/RAID#Firmware.2Fdriver-based_RAID
>
>     during early stage bootup, the RAID is implemented by the
>     firmware, and once the operating system has been more completely
>     loaded, then the drivers take over control.
>
>     Takze ten RAID v BIOSe nemusi pouzivat OS, ale musi tam byt inac
>     by z neho nebolko mozne napr. bootovat.  Samozrejme potom zalezi
>     uz na SW (asi toho bude schopny viac ako ten BIOSacky)
>
>
>     -- 
>     Matus UHLAR - fantomas, uhlar at fantomas.sk
>     <mailto:uhlar at fantomas.sk> ; http://www.fantomas.sk/
>     Warning: I wish NOT to receive e-mail advertising to this address.
>     Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
>     They that can give up essential liberty to obtain a little temporary
>     safety deserve neither liberty nor safety. -- Benjamin Franklin, 1759
>
>     _______________________________________________
>     https://lists.linux.sk/mailman/listinfo/linux
>     Meta FAQ: http://www.sklug.sk/lists/linux/metafaq.html
>
>
>
> _______________________________________________
> https://lists.linux.sk/mailman/listinfo/linux
> Meta FAQ: http://www.sklug.sk/lists/linux/metafaq.html

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linux.sk/pipermail/linux/attachments/20120127/11d03bbe/attachment.html>