Reiser4 (diskuse)

[Mirek]

Pokud chceš stahovat boot, tak doporučuji změnit msleepy v jádře u ide ovladačů a to z 50 na 5, mam to takhle všude a boot se zrychlí o cca 5 sekund.

[vogo]

no vzhledem k tomu, že obvykle bootuju jednou za den :) tak kouzla pro zrychlením bootu nijak zvlášť nehrozí :)

[Heron]

Taktéž jsem se přes týden trápil s rozdělením disku.

Původně to vypadalo takto:

hda1	ntfs	 37GB
hda2	ext3	 35GB (/)
hda3	reiser	  2GB (/var)
hda4	jfs	111GB (sklad)

Zjistil jsem, že do Windů vůbec nebootuju (a že v Cedega jedou hry docela obstojně), tak jsem zmenšil hda1 na 10GB a celé to přerozdělil:

hda1	ntfs	 10GB
hda2	ext2	512MB (/boot)
hda5	ext3	  2GB (/)
hda6	ext3	  8GB (/usr)
hda7	ext3	  4GB (/var)
hda8	ext3	 16GB (/home)
hda9	?	  2GB (bordel1)
hda10	?	  2GB (bordel2)
hda11	jfs	144GB (sklad)

Všechny oddíly jsou s noatime a ext3 navíc s dir_index, data_writeback, commit=60.

Výsledkem je velké zvýšení rychlosti práce s diskem. Nechápu proč, ale před rozdělením opera startovala cca 30s, teď 4s.

Ty dva bordel* oddíly mám na testy (a poštu), takže zkusím reiser4... Reiserfs 3.6 mně HODNĚ zklamal.

Proč to sem píšu? Protože mě opravdu VELMI překvapilo, jak moc byl ten FS po cca 1.5 roce neefektivní. Nechci rozpoutávat flame, ale NTFS už tam mám cca 3-4 roky a po občasném defragu je jako nový. Stále někde čtu, že linuxový FS se optimalizují samy a že defrag nepotřebují. Už tomu nevěřím.

[vogo]

no u mě po roce používání nijak velké zpomalení nebylo... a to jsem měl reiser 3.6 všude

[Jary]

Pokud máš plný filesystém, tak jeho algoritmus hledající volné místo asi bude hledat o dost delší dobu, než s poloprázným FS takže jestli náhodou toto není ten problém. Ve Windows je při defragmentaci myslím nutné mít 7% volného místa (u toho MS "defragmentátoru"), takže bych to bral za jakési vodítko i pro Linuxové FS, pro orientaci kolik asi by mělo ve FS zbývat volného místa, aby práce s ním byla efektivní. Ale je to jen taková moje doměnka.

[Jary]

Domněnka je asi lepší.

[Heron]

JJ tohle vím, nikdy nepřesahuju víc jak 70% zaplnění. Ve windows taky nechávám cca 20% volnýho. Na NTFS používám OODefrag.

[Mirek]

S tou defragmentací souhlasím, moc to nefunguje, poznam to jednoduše, stahnu CD, nebo DVD nějaké linuxové distribuce přes torrenty a pak ho kopíruju někam jinam. Vždy to kopíruje poprvé rychlostí cca 3 MB za sekundu a až když to kopíruju někam jinam podruhé tak to kopíruje normálně asi 40 MB za sekundu. Tohle vše na posledním kernelu spolu s ext3.

[Heron]

Nebude to tím, že se při stahování použije sparse-file? Tomu bych celkem rozuměl, na začátku se vytvoří řídkej soubor o délce toho stahovaného souboru a postupně se tam cpou ty jednotlivý stahovaný bloky (v náhodným pořadí). Tohle dělá azureus i na NTFS.

[xxxxxxxx]

staci zaskrtnou polozku "postupne vytvareni souboru"

[Ctirad Feřtr]

Shodou okolností nedávno proběhly v linux audio user listu debaty a testy na téma nejvhodnější FS pro práci s audiem a reiser4 to tam na vzdory publikovaným benchmarkům projel na celé čáře. A to dokonce dost výrazně i v porovnání s reiserfs nebo ext2/3.

[Tom K]

Benchmarky na namesys, jako jakekoli benchmarky provadene autorem libovolneho produku bych nebral, jako relevantni. Me osobni zkusenosti a nekolik drobnych mereni rikaji, ze reiser4 potrebuje mit k dispozici spoustu procesoroveho vykonu, aby byl jakz takz pouzitelny a napriklad v blokovem cteni a zapisu je na tom velmi velmi zle. Takze boot se mozna zrychli, kdyz CPU nedela nic, nez taha data z disku do pameti. Realny provoz, kde by se CPU mel zabyvat jinyma vecma, nez resit silenou rezii FS je na tom malinko jinak.

[Luboš Doležel (Doli)]

Reiser4 je kepl. Naposledy jsem ho zkoušel před pár měsíci a letělo to hned - byl to jeden deadlock aplikace za druhým...

[al-Quaknaa]

Možná to bude právě proto, že jsi reiser4 zkoušel

před pár měsíci

. On totiž vývoj opravdu velkým tempem pokračuje a například vytuhávání při upgradu jádra 2.6.13 => 2.6.14 už je taky dávno minulost. A přestože filesystémům moc nerozumím (proto si nebudu hrát na odborníka), ty možnosti, které reiser4 zdá se přináší, jsou myslím moc hezké a snad (?) i revoluční. Nevím, každopádně hodnotit ještě ne oficiálně vydaný soft není tak docela čestné.

[jm]

On totiž vývoj opravdu velkým tempem pokračuje a například vytuhávání při upgradu jádra 2.6.13 => 2.6.14 už je taky dávno minulost.

To nepochybne

Viz napr. nasledujici chovani pri spusteni OO.org 2

Kernel BUG at fs/reiser4/plugin/file/tail_conversion.c:29
invalid opcode: 0000 [1] PREEMPT
last sysfs file: /class/net/eth1/ifindex
CPU 0
Modules linked in: usbcore eth1394
Pid: 10184, comm: soffice.bin Tainted: P   M  2.6.16-rc1-mm4 #1
RIP: 0010:[<ffffffff801c8317>] <ffffffff801c8317>{get_exclusive_access+31}
RSP: 0018:ffff810007cfde78  EFLAGS: 00010282
RAX: ffff81001e4d6730 RBX: ffff810006415670 RCX: 00000000f3ab8000
RDX: 00000000f3ab7000 RSI: 0000000000000000 RDI: ffff810006415670
RBP: ffff81001e4d66c0 R08: 0000000000000000 R09: ffff810014dd5f40
R10: 0000000000000293 R11: 0000000000000293 R12: ffff810006415670
R13: ffff810007cfdf50 R14: 0000000000000001 R15: 0000000000000000
FS:  00002ab0122a5b00(0000) GS:ffffffff805f7000(0063) knlGS:00000000f66606c0
CS:  0010 DS: 002b ES: 002b CR0: 000000008005003b
CR2: 00002ab012776000 CR3: 000000000cbe9000 CR4: 00000000000006e0
Process soffice.bin (pid: 10184, threadinfo ffff810007cfc000, task
ffff810010dd9730)
Stack: 00000000f3ab7000 ffffffff801c78b7 0000000000000000 ffff810014dd5f40
       000000011de53440 000000000000bd18 0000000000000000 ffff810006415700
       ffff810007cfdf50 00000000f3ab7000
Call Trace: <ffffffff801c78b7>{write_unix_file+753}
       <ffffffff80168181>{vfs_write+175} <ffffffff801682d0>{sys_write+69}
       <ffffffff8011c0b4>{cstar_do_call+27}

Code: 0f 0b 68 78 71 45 80 c2 1d 00 48 89 df e8 9a 5a 25 00 c7 43
RIP <ffffffff801c8317>{get_exclusive_access+31} RSP <ffff810007cfde78>

Pote uz na dany oddil az do rebootu nic nezapises. Verze jadra? 2.6.16-rc1-mm4

A přestože filesystémům moc nerozumím (proto si nebudu hrát na odborníka), ty možnosti, které reiser4 zdá se přináší, jsou myslím moc hezké a snad (?) i revoluční.

To nepochybne, totalni havarie pri spusteni aplikace je opravdu revolucni featura.

Nevím, každopádně hodnotit ještě ne oficiálně vydaný soft není tak docela čestné.

Ale no to snad neee... Vzdyt pan autor to tlaci do vanilla jadra uz od verze 2.6.13, tusim. :-P

[JaMa]

Jo tohle presne jsem parkrat taky obdrzel na 2.6.16-rc1 a rc3. Bud pri pouzivani OO.org nebo vmware.

Ted po upgradu na 2.6.16-nitro-git[238] se mi to zatim nestalo.. (bug fixu tam je celkem dost)