Portál AbcLinuxu, 2. května 2025 03:23
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.
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é.
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
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
Tiskni
Sdílej:
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.