Přecházet z reiserfs na ext4?!

11.3.2008 11:38 | Přečteno: 2450× | Za vším hledej Linux

Při nedávno zmíněném pohovoru jsme mimo jiné semleli i záměr firmy přejít z reiserfs na ext4. Osobně jsem byl překvapen tím, proč by to někdo vůbec dělal? Pochopitelné je to pro mne tam, kde je primárním souborovým systémem ext3, ale proč přecházet z osvědčeného reiserfs na vývojový ext4?

Jak vidno současná (a dosud neuzavřená) tahanice s Reiserovou manželkou má mnohem hlubší dopady než by si kdo pomyslel. Lze mít odůvodněné obavy o osud souborového systému reiser4, jehož vývoj není dosud ukončen, ale jakou souvislost to má s reiserfs, který už je nějaký ten pátek v hlavním stromu jádra? Pokud vím, tak ext4 řeší především slabiny ext3, ovšem proti reiserfs nic moc extra převratného nepřináší. Nebo se mýlím?

       

Anketa

Komentáře

[Ignor]

Jak vidno současná (a dosud neuzavřená) tahanice s Reiserovou manželkou má mnohem hlubší dopady než by si kdo pomyslel.

Z toho, co jsi napsal, spíš jasnovidno než vidno. Ale pokud má někdo problémy s reiserfs tak samozřejmě má smysl přejít jinam Ovšem přecházet na nový a neodzkoušený ext4 asi nemá smysl nikde, kde o něco jde.

[Heron]

Mě celkem překvapilo / zděsilo, že se ext4 má dostat do Fedory 8. Tedy nikoliv jako default FS, ale zkrátka bude ve výběru. Což je zvláštní v době, kdy sami vývojáři ext4 uvažují o zavedení speciálního parametru (test_fs nebo tak nějak), bez kterého ten FS nepůjde ani namountovat.

Úvaha o přechodu ze stabilního FS na vývojový mi připadá přinejmenším předčasná. Ale kdo chce kam...

[Dalibor Smolík]

Na testovacím stroji bych to klidně vyzkoušel. Ale do ostrého provozu ... nevím. Asi bych nespal.

[Heron]

Takový malý testovací produkční servřík Taky to testnu, jasná věc. Ext4 bude značné omlazení tohoto FS. Ext3 je dobrý FS. Takový konzervativní a "just works". Ale má svůj věk (což jednak znamená vysokou stabilitu, ale také nedostatky).

[Dalibor Smolík]

Pravda je, že od samého začátku používám ext3 (tedy před tím ext2), jsem konzervtivní ... ext4 vyzkouším. Časem z něj bude určitě standard.

[freshmouse]

Kdo si sám volí souborový systém, měl by mít tolik znalostí, že ví, co dělá. Je nějaký důvod, proč tam jako volitelný souborový systém Ext4 nedat? (A má to být Fedora 9, ne 8, nemýlím-li se.)

[Heron]

Jo F9, uklepl jsem se.

Však já také netvrdil, že tam ext4 být nesmí. Ale zdá se mi poněkud předčasné to nabízet už během instalace. Ale do vydání F9 je ještě daleko, tak uvidíme jak to nakonec vyřeší a jestli tam ext4 na výběr vůbec bude. Pochopitelně nikomu nic nebrání si zkusit ext4 již teď.

[tsLnox]

já se zatím držím osvědčeného ext3 Ale o reiserfs sem před instalací gentoo taky chvíli uvažoval...

[ja]

Tak bu rad, ze len uvazoval. Ja som mal uz komplet skompilovane gentoo na ext3 potom som sa uz ani neviem z akeho dovodu (problemy s ext3 to urcite neboli lebo doteraz som nemal ani jeden jediny) rozhodol to cele preprasit na reiserfs (pozor - nie na vyvojovu 4-ku - taky masochista nie som) a po nejakych bezdovodne (z mojho ext3 pohladu) som to robil cele poslusne naspat. Sorry - ale rusom neverim

[Aleš Kapica]

To mi vážně hlava nebere. Komentáře v diskuzi mi jen potrdily moje přesvědčení že na produkční stroj by něco podobného nasadil asi jen blázen. Přesto, v anketě většina prozatím hlasovala pro přechod. Že by jistá forma recese? Kolik z těch co hlasovali pro přechod asi tak má s reiserfs špatnou zkušenost? Mají s ním vůbec nějakou zkušenost?

[Michal Kubeček]

Podle mne je to způsobeno tím, že dokud si člověk pozorně nepřečte celý blogpost (a mám podezření, že nemalé procento čtenářů nejdřív hlasuje a pak čte), není moc jasné, jestli je řeč o ReiserFS 4 nebo ReiserFS 3.6. Přiznám se, že asi tak do poloviny jsem měl spíš pocit, že jde o čtyřku.

[David Watzke]

ReiserFS se pokud vím říká verzi 3.6, čtyřka je prostě Reiser4.

[ajikdpoe]

pouzivam uz roky ext2 a som spokojny, o ziadne data som neprisiel, nemusim sa trtkat s initrd :)

[Käyttäjä 11133]

To by si nemusel ani kdyby si si dal ext3 do kernelu

[Michal Kubeček]

A naopak... :-)

[Aleš Kapica]

Také používám už roky ext2 - pro obsah adresáře boot, který je na samostatném diskovém oddílu. Tam je jakýkoliv žurnálovací souborový systém holá zbytečnost. Ovšem to je také jediný diskový oddíl, kde používám souborový systém začínající na ext.

[Kvakor]

Ja mam take /boot na ext2 a je 99.99% casu namountovany jen jako readonly. Pro zapis ho premountovamam jen pri upgradu jadra.

[Ctirad Feřtr]

Initrd! Distribučníky, co kompilujou základní fs nebo dokonce řadiče disků jako moduly, bych věšel za koule do průvanu. Nerozumím tomu, že někdo může být schopen takového zvěrstva.

[disorder]

zakompilovat to tam vsetko naraz!

gentoo? prislusnik "unroll all loops church"?

[Michal Kubeček]

A proč by je neměli překládat jako moduly? K čemu je mi v jádře driver pro ReiserFS nebo JFS, když nikde žádný nemám (a někomu jinému zase ext2/ext3 a XFS)? K čemu je mi v jádře podpora deseti IDE řadičů a dvaceti SCSI, když mám na desce jen jeden a ještě k tomu SATA? A tak by se dalo pokračovat. Nemluvě o tom, že initial ramdisk je dnes často potřeba i z jiných důvodů než jen kvůli modulům (SW RAID, LVM, udev, ...), takže se mu stejně nemusíte vyhnout.

[Ctirad Feřtr]

Děláte si srandu? Co ušetřím tím, že dám pár mrňavých modulů pro 3 základní fs a čipsety do initramfs namísto do jádra? Ušetříte tím snad něco? Neušetříte. Stejně se to natahuje a tu paměť to zabírá. A co hůř někdy to není ani v tom initrd, protože instalátor do něj nacpal jenom ty moduly, co byly v počítači k dispozici v době instalace. Takže člověk změní desku a nefunguje to, změní harddisk za SATA a nefunguje to, rozhodne se na novém disku použít jiný fs a nefunguje to. A člověk se ani nikde nedočte, jak to má korektně vyřešit pomocí distribučních nástrojů.

[CET]

Hehe, jenom vzpominam, jak bych podobnou vec resil na Windows. Napada me pouze zkusit BartPE, ale netusim, jak bych Windows donutil, aby pouzili spravnej ovladac.

Pro Linux me napadaji aktualne 3 reseni:

1) Nabootovat z LiveCD (Knoppix, Slax, Ubuntu), pripojit oddil, udelat chroot a opravit initrd (obvykle je popsano v prirucce k distribuci)

2) Nabootovat z instalacniho media a zvolit mod rescue (pokud vim, ma ho fedora i debian, v ubuntu myslim taky je, ikdyz ubuntu install CD je zaroven liveCD) Postupy jsou take popsane.

3) Nabootovat nejakej sitovej Linux, napr. PLD linux (RAM disk only distro), nebo nejakej Linux pres NFS a opravit initrd jako v prvnim bode.

[Michal Kubeček]

Nevím jak vám, ale mně se obvykle v počítači pokoutně nemění základní hardware bez mého vědomí. Takže to spíš řeším tak, že případné potřebné moduly přidám (je to otázka opravy jednoho řádku v konfiguračním souboru a spuštění mkinitrd (a případně lilo)) ještě před výměnou hardware.

[alkoholik]

Nejlepsi je nechat v menu distribucni jadro i s pitomym initrd jako "rescue" polozku v lilu/grubu. Jinak ww se meni obcas dost neocekavane, kdyz odejde deska nebo jina dulezita soucast.

[otula]

Nevím jak vám, ale mně se obvykle v počítači pokoutně nemění základní hardware bez mého vědomí.

Dost často se mění hardware vědomě při výměně desky, která umřela – a to se špatně přidávají moduly před její výměnou

[Michal Kubeček]

Nouzové situace vyžadují nouzová řešení. Navíc nemám pocit, že by člověk s vlastnoručně přeloženým jádrem "na míru" na tom byl v takové situaci nějak výrazně lépe…

[otula]

To jsem ani netvrdil, jen jsem chtěl říct, že mnoho lidí mění hardware až tehdy, když se podělá. Sám si právě proto udržuji 2 jádra – jedno „univerzální“, abych mohl do systému nabootovat i když se něco semele, a druhé (aspoň v rámci mých znalostí) optimalizované pro daný počítač.

[pavlix]

Jj, já udržuju taky několik jader... jedno mam na diskou, ostatní na linuxových livecd/rescuecd, co jsem zatím stačil nashromáždit :).

[otula]

Rejpale
Abych nevypadal jako paranoik, tak to univerzální jádro je standardní distribuční, které se mi pravidelně samo aktualizuje. Přitom standardně používám druhé jádro, které si sám kompiluji. Má to i tu výhodu, že když náhodou při konfiguraci jádra něco zmrším a jádro mi pak zpanikaří, prostě nabootuji to distribuční jádro a všechno funguje bez jakékoliv práce navíc.

[trekker.dk]

V pohodě - live CD (osvědčilo se mi Gentoo instalační CD), chroot, make menuconfig, změnit co je potřeba, přeložit, nabootovat nové jádro.

Výhoda je, že v chrootu může člověk bez problémů fungovat i s jádrem, které bylo zavedeno z CD. Takže nový překlad jádra není absolutní nutnost, kterou je potřeba vyřídit hned.

[Michal Kubeček]

Děláte si srandu?

Nedělám.

Co ušetřím tím, že dám pár mrňavých modulů pro 3 základní fs a čipsety do initramfs namísto do jádra? Ušetříte tím snad něco?

Těch řadičů je podstatně víc než jen tři. A jejich počet stále roste. Takže ano, ušetřím.

A člověk se ani nikde nedočte, jak to má korektně vyřešit pomocí distribučních nástrojů.

V tom případě máte asi smůlu na volbu distribuce…

[Ondrej 'SanTiago' Zajicek]

Děláte si srandu? Co ušetřím tím, že dám pár mrňavých modulů pro 3 základní fs a čipsety do initramfs namísto do jádra? Ušetříte tím snad něco? Neušetříte.

Usetri se cas za inicializaci tech driveru, navic ramfs se muze po mountu uvolnit takze se usetri i pamet. Navic nektere drivery muzou navzajem kolidovat - napriklad libata PATA drivery vs klasicke IDE drivery.

A co hůř někdy to není ani v tom initrd, protože instalátor do něj nacpal jenom ty moduly, co byly v počítači k dispozici v době instalace.

njn, to neni problem initrd, ale jeho hloupeho pouziti. Me by se osobne nejvic libilo, kdyby initrd sestavoval sam grub na zaklade konfiguraku grubu - u jednotlivych bootovacich polozek v konfiguraku by uzivatel zadal jake prikazy se maji provest a jake moduly zavest a grub by sestavil initrd s prislusnymi prikazy, moduly a startovacim skriptem. Takze by to clovek mohl nastavit i pred bootem systemu rovnou z menu zavadece.

[Käyttäjä 11133]

Me by se osobne nejvic libilo, kdyby initrd sestavoval sam grub na zaklade konfiguraku grubu - u jednotlivych bootovacich polozek v konfiguraku by uzivatel zadal jake prikazy se maji provest a jake moduly zavest a grub by sestavil initrd s prislusnymi prikazy, moduly a startovacim skriptem. Takze by to clovek mohl nastavit i pred bootem systemu rovnou z menu zavadece.

Aha.. Takže Grub by měl obsahovat ovladače na všechna možná zařízení... Děkuji nechci.

[Ondrej 'SanTiago' Zajicek]

Ale nesmysl. Grub umi najit a precist soubor z ext3 (a dalsich filesystemu). Muze tedy krome samotneho jadra nacist i jaderne moduly z root filesystemu a pripravit z nich initramfs.

[Michal Vyskočil]

Navic nektere drivery muzou navzajem kolidovat - napriklad libata PATA drivery vs klasicke IDE drivery.

A to byl argument pro, nebo proti modulům?

[Ondrej 'SanTiago' Zajicek]

Pro moduly - uzivatel si konfiguraci iniramfs muze snadno zvolit, ktere drivery se pouziji. Zatimco kdyz by se oba zakompilovaly do jadra, tak by to asi delalo neplechu.

[Michal Vyskočil]

Jasně a já se hlavně ztratil v diskusi, jinak bych se tak blbě neptal

[Kvakor]

Na to je jedina odpoved - prelozit si vlasni jadro. Veci, co jsou v jadre porad dat na pevno, veci co muzou (ci musi) byt v modulech do modulu a zbytek vyhazet. A pokud neni rootfs na RAIDu, LVM nebo na necem podobne exotickem, neni treba ani initramdisk (udev muze pouzit klidne ramfs/tmpfs). Navic je initramdisk pres intird uz vlastne zastaraly, nova jadra na to maji initramfs pres cpio archiv.

[Michal Kubeček]

Na to je jedina odpoved - prelozit si vlasni jadro.

Za prvé: není důvod to dělat. Za druhé: jak už jsem psal, vlastní jádro vyřeší moduly, ale nic dalšího.

Navic je initramdisk pres intird uz vlastne zastaraly, nova jadra na to maji initramfs pres cpio archiv.

Použil jsem termín "inital ramdisk", nejmenoval jsem konkrétní implementaci.

Zmínka o udevu se týkala hlavně toho, že někdy potřebujete funkční udev ještě před přimountováním kořenového filesystému. Jednou jsem např. konfiguroval stroj, který detekoval síťová pole před lokálním SCSI diskem, takže (jaderné) jméno zařízení záviselo na tom, kolik těch polí bylo.

[David Jaša]

Jednou jsem např. konfiguroval stroj, který detekoval síťová pole před lokálním SCSI diskem, takže (jaderné) jméno zařízení záviselo na tom, kolik těch polí bylo.

Na to není vůbec udev potřeba - UUID=${příslušné_UUID} jako jméno zařízení fungovalo dávno předtím, než vůbec udev spatřil světlo světa (pravda, pro id, path a label to už nefunguje).

[Ondrej 'SanTiago' Zajicek]

UUID=${příslušné_UUID} jako jméno zařízení fungovalo dávno předtím ...

Ale tohle funguje pomoci initrd, ne?

[David Jaša]

Je to vlastnost linuxového mountu, která nemá s initrd nic společného. V mount (8) je to pěkně popsané:

       Most  devices are indicated by a file name (of a block special device),
       like /dev/sda1, but there are other possibilities. For example, in  the
       case  of  an  NFS mount, device may look like knuth.cwi.nl:/dir.  It is
       possible to indicate a block special device using its volume  label  or
       UUID (see the -L and -U options below).

...

       -L label
              Mount the partition that has the specified label.

       -U uuid
              Mount  the  partition  that  has  the specified uuid.  These two
              options require the file /proc/partitions (present  since  Linux
              2.1.116) to exist.

[Michal Kubeček]

Ale tady byla řeč o kořenovém filesystému, navíc při bootování bez initial ramdisku.

[David Jaša]

To snad řeší parametr jádra root=UUID=${UUID} zmínění níže...

[Michal Kubeček]

To chápu (i když je zvláštní, že třeba manuálová stránka k lilo.conf se o možnosti použít UUID nezmiňuje, ale o labelu ano). Jen jsem vás chtěl upozornit, že citovat v tomto kontextu manuálovou stránku příkazu mount je trochu mimo téma.

[David Jaša]

A je to vlastnost i jádra - místo root=/dev/sdxy v parametrech u zavádění mu lze také předhodit root=UUID=${UUID} .

[Ondrej 'SanTiago' Zajicek]

Myslim, ze jadro nepodporuje "root=UUID=${UUID}", ze tuhle funkcionalitu implementuje az prislusny initramfs, ktery parsuje kerneli commandline a podle ni zvoli root. Alespon ve zrojacich jadra jsem nic takoveho nenasel.

[Michal Kubeček]

Koukám, že dneska už se nedá věřit nikomu… Asi mi nezbyde než to vyzkoušet…

[David Jaša]

Sypu si popel na hlavu, je to jak píšeš.

(smajlík kvůli tomu, že jádro samo tuto užitečnou věc nezná).

[CET]

Initrd! Distribučníky, co kompilujou základní fs nebo dokonce řadiče disků jako moduly, bych věšel za koule do průvanu. Nerozumím tomu, že někdo může být schopen takového zvěrstva.

No, tak by sis nekdy o tom mohl neco precist, nez zacnes nekoho veset za cokoliv kamkoliv. Napr. kdybys mi ty udelal jadro s TVYM SATA radicem s EXT3 a ocekaval, ze si pujdu do svyho compu s IDE radicem kupovat tvuj SATA radic a disk, a ze misto reiserfs pro / partisnu pouziju ext3, tak bych te asi nakopal taky do zadku.

Initrd neni spatna vec. Pokud bys chtel kompilovat vsechno do jadra, tak bys bud generoval zbytecne obrovsky jadro, nebo bys delal tisice ruznych variant (radic, FS), nehlede na to, ze site bys treba nenabootoval vubec. Osobne jsem si delal initrd pro pripojeni NFS do Unionfs - tohle proste bez initrd neudelas.

[mseed]

Initrd nepouzivam, vse co potrebuji pri bootu mam v jadre. Plna spokojenost (Gentoo). Ale chapu ze uzivatele ostatnich dister maji initrd, protoze vetsinou uz nekompiluji sve vlastni jadro, ale pouzivaji distribucni, ktere musi bezet na mnoha ruznych strojich.

[disorder]

ja kompilujem svoje vlastne so vsetkymi vyhodami distribucneho (niet sa comu divit, tie balicky mi generuju distribucne skripty, na mne je len konfiguracia)

inac verim ze musi byt uzasna sranda zistovat co treba dokompilovat (a samotna kompilacia) ak sa ti dostane do ruk nejaky hardware. viva la plug'n'play!

[David Jaša]

Co je na tom za zvěrstvo? Jedno jádro pak jede na jakékoliv kombinaci filesystému a hardwaru a těch pár sekund navíc při bootu mi připadá jako velmi malá cena za tuto vymoženost.

[alblaho]

Statická prealokace inodů? Feudalismus! (Ale také robustnost

ReiserFS je dobře udržovaný, každý release jádra pro něj má několik oprav chyb. Kdo chce ultrakonzervativní ext2/3, tak prosím. Nicméně kdo něco takového chce, asi těžko půjde do FS pod těžkým vývojem.

Objektivní nevýhoda reiserFS je delší mountování. Já tedy tak velký disk nemám, tak jsem s ním spokojen. Na malé soubory je hezky rychlý bez jakéhokoliv tunění.

[Kvakor]

Nejnovejsi verze ovladacu reiserfs uz mountuji srovnatelne s jinymi fs. Kdysi mi to na 250GB disku trvalo cca. 10 sekund, dnes to trva pod jednu sekundu. Nejsis nejaka oddalena inicializace ci co (napr. prvni zapis na cersve namounotvany disk trva citelne dele).

[alblaho]

Jestli to zoptimalizovali, tak super.

Já mám největší oddíly pod 100GiB a trvá to tuším sekundu dvě... (2.6.22-14-generic).

Protože chápu že na terabajtech to mohlo dělat problémy.

[andree]

taky JFS a XFS su v jadre uz peknych par rokov, nechapem preco aj okolo nich nie je take halo ako okolo nejakeho reiserfs... neviem technicke detaily, ale myslim ze su minimalne podobne dobre navrhnute ako reiser, a vykonovo snad este lepsie... odladene za tie roky uz budu tiez celkom dobre (teraz pouzivam skoro vyhradne jfs a za tie 2-3 roky rebootov som na nom este o data neprisiel)

akurat na externom disku sa chova trosku divne ten JFS - aj ked dam `umount /media/disk; sync`, po novom pripojeni disku je potrebne spustit fsck.jfs (inak ho nemountne) - ale to je asi standardna vlastnost...

pocul som zvesti, ze resier vie lepsie vyuzit miesto, ak je vela malych suborov... neviem ci par mb na disku stoja za tie problemy...

[andree]

http://www.linux.com/feature/119025 - zaujimavy clanok o JFS btw, jfs pochadza z IBM/AIX|OS2 - co je asi trosku vacsia ryba ako reiser ;)

[mseed]

ReiserFS pouzivam uz mnoho let, bez nejmensich problemu. Hodi se na disky, kde je mnoho malejch souboru (Treba /usr/portage :) ).

[onion]

JFS ma jedinou vadu ... nejde zmensit :(

[David Jaša]

Na čistě linuxové filesystémy používám už nějakou dobu také JFS a jsem s ním ze všech linuxových FS nejspokojenější - sice v ničem nevyniká, ale narozdíl od ostatních nemá žádné slabé stránky...