Az Ubuntu is dobná a ReiserFS-t a telepítőjéből

Ubuntu

A nyár közepén Christian Perrier Debian karbantartó azt kérte, hogy mivel a testing telepítőjének kernelcsomagjai (.udeb) között már nem szerepel a reiserfs-modules csomag, távolítsák el a partman-reiserfs csomagot is, mert az előbbi nélkül nincs értelme, hogy legyen belőle .udeb a Debian telepítőhöz. Kérésének eleget is tettek.

Az ubuntu-devel levelezési listán Colin Watson jelezte, hogy a Debian dobta telepítője kernelcsomagjai közül és a telepítőjéből a ReiserFS-t, majd közölte, hogy a Debian nélkül nem nagyon szeretné karbantartani ezt a fájlrendszert az Ubuntu számára. Azt kérdezte, hogy van-e valaki, aki mindenáron ragaszkodik a karbantartásához, vagy dobhatja-e végleg.

Voltak, akik félreértették a helyzetet és azt javasolták, hogy nyugodtan lehet dobni a ReiserFS támogatást a kernelkonfigból és a telepítőből is.

Volt, aki jobban átlátta a helyzetet és szólt, hogy a kernel .udeb-ekből (a telepítő kernelcsomagjai) kellene csak dobni a ReiserFS-t és nem kellene az Ubuntu kernelcsomagok konfigjaiból, ugyanis az utóbbi azt eredményezné, hogy a felhasználók a következő kiadásra frissítés után a már korábbról meglevő ReiserFS fájlrendszereikhez nem tudnának hozzáférni. Colin Watson egyetértett ezzel helyzetértékeléssel.

A terv jelenleg tehát az, hogy a telepítőből (beleértve a telepítő kernelcsomagjait is) kiszedik a ReiserFS támogatást, viszont az Ubuntu telepített kernelei továbbra is támogatni fogják ezt a fájlrendszert. Vagyis új telepítéskor már nem lesz támogatott a ReiserFS fájlrendszerre való telepítés, viszont aki dist-upgrade-el, azt emiatt nem éri hátrány, továbbra is használni tudja/megtarthatja meglevő ReiserFS fájlrendszereit.

( hrgy84 | 2013. 09. 13., p – 12:15 )

Kar erte. Bar legrosszabb esetben debootstrappal meg elo lehet allitani ReiserFS alapu rendszert.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

Miért? Mi van/volt benne olyan kiemelkedően jó, hogy érdemes legyen megtartani?
Én nem nagyon hallottam, hogy valahol élesben használnák.
(illetve itt írta valaki, hogy squid alá tette)

Akit tudja, csinálja, aki nem tudja, tanítja... Hm... igazgatónak talán még jó lennék. :)

Ha jól emlékszem az ext2 mellett akkoriban már megbízható naplózó fs-nek számított. Ezidőben az ext3 még csak szárnybontogatás volt. Gondolom a régijólbevált FS-t sokan nehezen cserélik le egy kevéssé ismertre, mert szintén a régi és sűrűn előforduló FS hiba emlékek törnek a felszínre. Csakhogy azóta már jóval szélesebb a felhasználói bázis és jóval több gépeb futnak az fs-ek, illetve elég komoly cégek kerültek be a Linux kernel mögé.

Én egyszer akartam használni ext2 helyett (vagy már ext3? Fene se emlékszik).
Akkor kicsit utánajártam és volt benne valami durva, potenciálisan adatvesztést okozó bug, ami miatt mindenkit lebeszéltek róla. Részemről ott véget ért a pályafutása. Utána meg már tényleg jött az ext3 és a továbbiakban nem foglalkoztam másikkal.

Akit tudja, csinálja, aki nem tudja, tanítja... Hm... igazgatónak talán még jó lennék. :)

Nalam az ext3 nyutott ebben a sportagban kiemelkedo teljesitmenyt. Volt egy VMware szerverunk, nem ESX, hanem a regi fajta cucc. Ext3 volt a fajlrendszere, es volt egy aramszunet. Csont nelkul helyreallitott minden fajlt - a lost+found-ba, #4649846 neven. Mivel a VMware Server defaultja (legalabbis azon a gepen) az volt, hogy splitted diskeket csinal (4G-onkent szetszedi fajlba), gyakorlatilag 100%-os adatvesztesunk volt, mert a szam nevek alapjan nem lehetett a diszkeket osszeparozni.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

Pl. ext3 ig agyon verte sebességben kb bármelyik alternatívát, nagyon sok debianos gépet "upgradeltem" érezhetően gyorsabbra azzal, hogy reiserre cseréltem a filerendszerét. Amikor elkezdődött ez a hülyeség, hogy Reiser börtön stb. és a debian etlepítőből kiszedték a támogatását, akkor néztem utána milyen alternatívák vannak. Az ext4 nem tetszett, de akkor a btrfs sem még, maradt a reiser, a telepítő megkerülésével. Mostanra meg btrfs, de akkor is kár a reiserért...

Igen, ilyet is csináltam már. Jelenleg azonban az egész egyetlen partíciót használ, aminek a backend-je egy zvol... A netbook-omon más a helyzet, ott ext4 van az LV-ken a TRIM miatt, de a portage alattin természetesen reiser. A PORTAGE_TMPDIR alatt meg tmpfs volt eddig, újabban zram. A BTRFS nem mozgat, ZFS-hívő vagyok. De ide meg felesleges.

Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn

A héten beszart az asszony netbookjának töltője, így most improvizálnom kell. Van itthon egy nagyon low end laptop (Celeron 1,4 GHz, 1 GB RAM). Most előszedtem, hogy amíg az új töltő nem jön meg, tudjon valamivel internetezni. Lubuntu megy rá és ha a telepítő engedi, akkor ReiserFS lesz az alapja.

--
trey @ gépház

( golgota | 2013. 09. 13., p – 12:35 )

ideje volt már elkezdeni a szart kilapátolni szép lassan

Volt egy file-om, amit rendszeresen elfelejtett. Pontosabban 0 hosszúságra tudta redukálni (szabályos rendszerleállítás mellett is) Biztos volt más oka is, nem csak önállóan a reiserfs, de más filerendszerrel sose jött össze ez a bug. Akkor megszabadultam tőle, azóta is a legtöbb rendszeremen xfs van.

milyen bugokat? mit kene fejleszteni rajta? amit egy fs-nek tudnia kell azt tudja. amiket a zfs/btrfs csinal (raid, snapshot etc) annak szerintem semmi keresnivaloja egy fs-ben, azt blokk layerben kene kezelni...

en is 10+ eve hasznalom, rengeteg eles szerveren is, sose volt vele problemam, se adatvesztesem. sot nagyon halott vinyorol, ami tele volt badsectorral, is visszanyert a reiserfsck minden fontosat.

ugyanakkor nem kell sose szopnom fsck-val, akarmilyen szabalytalanul allt meg a gep vagy a disk.

A'rpi

Régebben olvastam komoly bugokról.
Nekem volt párszor olyan, hogy fs összekavarodott. Volt, hogy megoldotta, volt hogy nem. Mondjuk nem csak reiserrel jártam így, ext2 vagy ext3 is összekavarodott egyszer.

Valamikor régen olvastam egy cikket, amiben valami komoly bugról volt szó, amit a 3-asban találtak, és akkor az volt a mondás, hogy a 3-ast már nem fejlesztik, mert jön a 4-es. De aztán a 4-es mégsem jött, mert Reiser börtönbe ment.
Legalábbis így emlékszem.
Persze lehet, hogy azóta egy karbantartó csapat Reiser úr nélkül a kezébe vette a hármas javítását és a korábbi komoly bugokat kijavították, az is lehet, hogy már a 4-es számút is befejezték Reiser nélkül.
Nem tudom, nem követem.

Arra utaltam az eredeti kérdésemben, hogy régen voltak benne ismert bugok, és az, hogy most kevés a panasz, több dolog miatt is lehet. Pl. kevesen használják, vagy a bugokat megjavították, vagy valami olyan módon használják az emberek manapság, ami nem hozza elő a még ki nem javított bugokat, vagy más hasonló.

Mivel fogalmam sincs, hogy kb. 10 éve mi történik ezzel az fs-sel, ezért kérdeztem.

Trey és a te válaszod alapján akkor ha jól értem, van valami karbantartó csapat, akik az összes bugot kijavították, még mindig igen sokan használják a reiserfst, és azért nincsenek panaszok, mert kiválóan működik.

Jól értem?

http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/log/?qt=…

Te komolyan gondolod, hogy a ReiserFS-t csak Reiser személyesen tudja fejleszteni / javítani?

http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/MAI… 

REISERFS FILE SYSTEM
L:	reiserfs-devel@vger.kernel.org
S:	Supported
F:	fs/reiserfs/

--
trey @ gépház

No igen. Ez megint a "melyiket harapjam meg?" kérdéskör...
Logikailag ugyanis továbbra sem tudom beleilleszteni, de ebben tényleg van valami.
(mióta láttam közel 12 órán át szinkronizálódó, tükrözött diszkpárt, ami azért rendesen megfogta a rendszert...)
Bár akkor inkább valami olyat tudnék elképzelni, mint SSD esetében a trim(???) funkció, de ehhez a RAID szofver együttműködése is kellene.

Akit tudja, csinálja, aki nem tudja, tanítja... Hm... igazgatónak talán még jó lennék. :)

Számomra a RAID inkább hardverhez kapcsolódó fogalom, a fájlrendszer meg már a szoftveres oldalt képviseli.
Értelmesebben nem tudom megfogalmazni.

Végeredményben a RAID-re nem kell feltétlenül fájlrendszert tenni (lásd Oracle raw device), ha meg a fájlrendszer egyben RAID funkciókat is ellát, akkor pl. macerásabb lehet a mozgatása (állítólag a szoftveres és a hardveres RAID-et nem célszerű keverni)

Akit tudja, csinálja, aki nem tudja, tanítja... Hm... igazgatónak talán még jó lennék. :)

Ha nagyon akarna, a RAID is kovethetne, hogy mely blokkok foglaltak, ehhez nincs ertelme a fajlrendszertol fuggeni. Raadasul neki teljesen mas jellegu informaciora van szuksege, mint a fajlrendszernek, mert nem azt kell tudnia, hogy mely blokkokon van fajl, hanem hogy mely blokkok modosultak, aminek valojaban semmi koze nincs ahhoz, hogy ott van-e fajl vagy nincs.

A kulonallo RAID azert jo, mert a RAID altal elvegzett funkcionalitast ki lehet szervezni celhardverbe (RAID kartya ugye), ami - tekintve, hogy joval kisebb teljesitmenyu, mint az egesz gep - jobban es egyszerubben vedheto adatvesztes ellen. Ha viszont a fajlrendszerrel van egybeepitve a RAID, akkor az egesz pont ugyanannyira lesz serulekeny, mint amennyire a fajlrendszert futtato gep maga.

Persze, tegyunk ketszazezer orat ativelo UPS-t, es akkor nem lesz gond. Kiveve, ha az UPS rendszer elszall.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

Természetesen nem vezetek statisztikát.
Ez egy benyomás, a saját ismerőseim körében, a különböző fórumokon (pl. ebben a hup bejegyzésben), és pl. a hup rendes éves szavazásának az eredményeképpen.
Nekem úgy tűnik, hogy volt idő, amikor nagyon sokan használták (pl. én is sok helyen), és aztán visszaszorult.
Persze lehet, hogy tévedek, és még mindig baromi sokan használják, csak ezeket az embereket én nem ismerem, fórumokba nem írnak és szavazni se nagyon szavaznak.

Feltételeztem, hogy a debian telepítőből kikerülése is az elterjedtségével, illetve az új telepítéseknél a reiserfsre való igény alacsony szintjével lehetett összefüggésben.

Persze, de ez rossz pillanatban érkezett. :)
Ennyi év után nem is emlékszem a részletekre.
Valami reprodukálható, adatvesztéses hiba rémlik, de nagyon rég volt, utánanézni meg lusta vagyok.

Akit tudja, csinálja, aki nem tudja, tanítja... Hm... igazgatónak talán még jó lennék. :)

( gajdospajtas | 2013. 09. 13., p – 12:37 )

mondjuk én csak squid proxy alá használtam a notail opció miatt.

( wachag | 2013. 09. 13., p – 16:47 )

Troll on
> hogy a Debian nélkül nem nagyon szeretné karbantartani ezt a fájlrendszert az Ubuntu számára

Ebből is látszik, hogy végülis az érdemi munkát mindig is a debianosok csinálták, az Ubuntu csak a skint adta.

Troll off