48 bit: A jó öreg ext3 ráncfelvarrása

Kernel

Az IBM-es Mingming Cao és csapata azon dolgozik, hogy a Linux eredeti filerendszerét (etx2 -> ext3) kicsit aktualizálja. Mint levelében írta, az ext3 jelenleg 8 terabyte-ra (4k block méret) limitált. Ez nem elegendő napjainkban vagy a közeljövőben, ahol egyre nagyobb az igény a nagy tárterületek iránt.

Ezért négy cég, a RedHat, a ClusterFS, az IBM és a BULL azon dolgoznak, hogy az ext3-at 32 bites filerendszerből 48 bitesre alakítsák, és ezzel a jelenlegi 8 TB-os limitációt 1024 petabyte-osra növeljék.

A változtatásokhoz szükséges patch-ek elkészültek, és egy részük már az Andrew Morton-féle -mm fában van. Ezért Mingming egy RFC-t nyújtott be az LKML-re, amelyben vitára bocsátotta az alap Linux filerendszer megbolygatását. Hát vita lett is belőle. Volt aki egyetértett a javaslattal, volt aki nem. Meglehetősen nagy lett a szál.

Linus csak ennyit mondott rá:

"Quite frankly, at this point, there's no way in hell I believe we can do major surgery on ext3."

Akinek van ideje és türelme végigolvasni, kezdje itt.

( bastya_elvtars | 2006. 06. 12., h – 08:55 )

Nézzétek el nekem, de Linuxos filerendszerek terén butácska vagyok. Miért nem a Reisert favorizálják inkább? (Ha kiforratlan, akkor épp ezért kéne azt, mert állítólag több van benne.)

Fordítottnak biztosan nem fordított, viszont tapasztalatból azt mondhatom, hogy a teljesítménye határozottan rosszabb a reiser3-nak, mint az ext3-nak. Eleinte én is meglepődtem rajta, mert a bonnie, meg ilyen toolok tőbbnyire a reisert hozzák ki jobbnak, de pl egy installpkg lefutási idejében nagyságrendi eltérések vannak az ext3 javára.
---
Apparently the human mind is not unlike cookie dough.

( syntern | 2006. 06. 12., h – 09:12 )

Két kérdés:
- miért nem lehet beolvasztani, és akinek kell, az majd használja?
- próbáltátok már a ZFS-t? (Tudom, Solaris, és erre itt sokan fújnak, de a demók alapján nekem nagyon impresszívnek tűnt)

"- miért nem lehet beolvasztani, és akinek kell, az majd használja?"

Mert ez az ősi Linux FS, sok régi felhasználó függ tőle, nem akarják ezt összebarmolni, így is "pretty damn messy." - mondta Linus.

- próbáltátok már a ZFS-t? (Tudom, Solaris, és erre itt sokan fújnak, de a demók alapján nekem nagyon impresszívnek tűnt)"

Van ZFS Linuxra? Én nem tudok róla ;-)

--
trey @ gépház

Én ami ZFS demót (flash movie) látam, az azt mutatta be milyen jól és gyorsan lehet particionálni, mirrorozni, stb.
De sebességtesztet, és valódi felhasználást még nem láttam. Valaki?

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee."
-- Ted Ts'o

De nyilván lesz. Engem meg érdekel a jövő szele.

Egyébként szerintem ez egy ext3 topic ami egy fs.
Ez itt meg a legjobb magyar unix portál ami != linux.
Vagy tévedek? ;)

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee."
-- Ted Ts'o

( peep | 2006. 06. 12., h – 09:29 )

Azon gondolkoztam, hogy haza ext3 8terrát bír akkor a NTFS mennyit(mert gondolom egy wines szerver ezen futkosna)..nem flame-et akarok indítani, csak a kíváncsiság hajt :)

http://en.wikipedia.org/wiki/NTFS :

Maximum Volume Size
In theory, the maximum NTFS volume size is 264-1 clusters. However, the maximum NTFS volume size as implemented in Windows XP Professional is 232-1 clusters. For example, using 64 KiB clusters, the maximum NTFS volume size is 256 TiB minus 64 KiB. Using the default cluster size of 4 KiB, the maximum NTFS volume size is 16 TiB minus 4 KiB. Because partition tables on master boot record (MBR) disks only support partition sizes up to 2 TiB, you must use dynamic volumes to create NTFS volumes over 2 TiB.

( noss | 2006. 06. 12., h – 09:43 )

'márpedig 1024 petabyte mindenkinek elégnek kell lennie'
/me, 2006. júni ;P

( uid_228 | 2006. 06. 12., h – 09:49 )

Lehet, hogy hülye kérdés, de miért nem 64 bitesre alakították át 48 helyett, esetleg tudja valaki?

--
Sokan nincsenek tudatában annak, / hogy egyszer mindenki meghal. / Akik ráébrednek erre, / azonnal abbahagyják az ellenségeskedést.

Hogy 10 év múlva megint jöhessen egy új ráncfelvarrás... :)

Elvégre a gyerekeik munkalehetőségére is gondolniuk kell. Egy programozónak nem érdeke a tökéletes munka. :)

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee."
-- Ted Ts'o

"Hogy 10 év múlva megint jöhessen egy új ráncfelvarrás... :)"

Hat, IMHO 10 ev (5 ev) mulva a hagyomanyos mechanikus tarolokat szepen lassan cserelgetni fogjuk memoriakartyas megoldasokra. Mar ma is itt-ott latni/hallani rola es gyartjak is, csak meg draga.

Egy ilyen memoriakartyas tarolohoz nem biztos, hogy a legszerencsesebb valasztas egy mechanikus eszkozokre optimalizalt FS (gondoljunk arra, hogy fejmozgas, savok, szektorok nincsenek). En biztos vagyok benne, hogy meg fognak jelenni egy-ket even belul a kifejezetten ezekre az eszkozokre hegyezett FS-ek is, ha arban elerhetobbek lesznek ezek az eszkozok. Az majd egy ujabb verseny lesz. :-)

---------------------
Ригидус а бетегадьбол

Van már flash-drivera optimalizált fs, ha nagyon érdekel utánanézek (jfs vagy vmi ilyesmi).

Igazad van a tendenciával kapcsoaltban, biztos ők is ezért gondoltak csak 48 bitre. :)

Mondjuk nem hiszem, hogy teljesen kiszorítaná a memóriakártya a hdd-ket, csak más lesz a felhasználási területük mint ma.
Elvégre még mindig vannak szalagos egységek...

Amíg az egy bitre jutó költség kisebb a hdd-knél mint a memóriáknál, nem lesz kidobva a süllyesztőbe.

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee."
-- Ted Ts'o

"Mondjuk nem hiszem, hogy teljesen kiszorítaná a memóriakártya a hdd-ket, csak más lesz a felhasználási területük mint ma."

Kezdetben szerintem is csak a felhasznalasi teruletek fognak atcsoportosulni, de hosszutavon (ha fejlodokepes marad) akkor teljesen kitolti azt az urt amit a mai mechanikus tarolok.

- joval nagyobb a hibaturese
- nem tartalmaz mechanikus alkatreszt (kivetel talan a hutese)
- eleg valoszinu, hogy a fogyasztasa is alacsonyabb
- hosszabb elettartam
- fizikai behatasokra ellenallobb, tehat a szallitasa egyszerubbe valik (pl mai mechanikus tarolok csomagolasa kb 8x-10x akkora mint maga a diszk)
- seeking muveletekben gyorsabb (lesz) mint barmilyen "fejrangatos" versenytarsa is valaha

Nekem itthon van egy "szerverem" amiben kiserletezek egy 4GB pendrive-val (lol) Hatarozottan elegedet vagyok vele a natbox-on. :-)
(egyedul a bootolasa gazos meg, mert abbol a biosbol nem tud)

---------------------
Ригидус а бетегадьбол

Ja, meg arra nem reagaltam, hogy 48 bit. Szerintem a merevlemez meg rovid, kozep tavon dominal, ugyhogy teljesen meg nem dobjak felre, de egy nagyobb ext3 fejlesztes 64bit-re mar eleg tavoli jovonek tunik, hogy merevlemezekre alapozva nekiugorjanak. :-)

---------------------
Ригидус а бетегадьбол

Fogalmam sincs.
http://www.seagate.com/cda/products/discsales/personal/family/0,1085,75…
Ez alapján egy 750 GB-os diszk seek idején 13W-ot fogyaszt, átlagra pedig 3W-ot írnak (persze ezek desktop diszkek, szerverben ennél nyilván magasabb).
Két ilyen diszk már hibatűrő, az legrosszabb esetben 26W. Köré még kell némi elektronika, stb. Szerintem legfeljebb 50-100W-ból megoldható.

Koszi. Igy most mar tudom hova tenni a fenti megoldast. :-)
Akkor azert van meg hova fejlodni.

Egyebkent ez mitol ennyire sok? Csak mert abbol indultam ki, hogy egy 4GB pendrive is kb 0.5-1W korul lehet, viszont ebbol kiindulva, 4GB-s kartyakbol 250-500w korul ki tudnam hozni ugyanazt mint a fenti 2,500w-os.

Szal mitol ennyire sok ez?
Ennyire sokat dob ra homersekletben a tartos igenybevetel? (hutesre gondolok elsosorban)

---------------------
Ригидус а бетегадьбол

( golgota | 2006. 06. 12., h – 10:04 )

Én most má télleg csak azt nem értem, miért nem a JFS-el nyomulnak,ami az IBM kutyájának a kölke, aki ugye bent van a dzsemboriban. Mondjuk csak 4 petabyte a maximum, de szerintem ezt könnyebben lehetne masszírozni, mint az ext3-at.

Nagyon régen használtam XFS-t , még a 2.4-es kernelbe olvasztás tájékán, akkor nekem azon kívül, hogy desktop célra lassabbnak tűnt mint az ext3 más bajom nem volt vele, kiváncsi lennék egy recent 2.6 -os kernellel mért sebességtesztre mondjuk ext3 vs. xfs vs. jfs vs. reiser3 vs.reiser4

Ha tud valaki ilyet ne habozzon...

Üdv
Godot

Nagyon jó sebességeket tud az XFS hozni, de Debian Sarge alatt, 2.4.31-32-es kernellel és MySQL-lel jól megtekerve "Elszállt, mint a viadukt..." (Matuska Szilveszter verse :))). Reprodukálhatóan előjött nekem régebben a hiba többször is; s az egész kernel blokk I/O-réteget megfogja, mert a fizikailag külön vinyóra kirakott syslog (szinkron írással, jó gyors legyen) se mutatot semmit.

Végül némi kuglis turkálással találtam meg a megoldást, bár ott valami 2.6.10-12-körüli kernelt anyázott a hozzám hasonlóan járt ember, ergo abban a verzióban még megvolt a hiba. Amióta a partíciót átformáztam Ext3-ra, semmi baja.

Tehát XFS+MySQL=vibrátoros szopóautomata. :)))

--
Sokan nincsenek tudatában annak, / hogy egyszer mindenki meghal. / Akik ráébrednek erre, / azonnal abbahagyják az ellenségeskedést.

Egyébként ezt én sem értem. Ezt az energiát lehetne az Ext3-as csiszolgatására is fordítani.

Több helyen is nézegettem teszteket linuxos filerendszerekről. Hol az egyik gyorsabb, hol a másik, a terhelés fajtájától függ. Nem állítom azt, hogy az Ext3 a létező legjobb filerendszer, de ahol hátrányban maradt, ott általában nem sokkal. A végszó tkp. szinte mindig ugyanaz volt: az Ext3 nem tűnik ki igazán semmiben, de egy jól kiegyensúlyozott és átlagban elég jó teljesítményt nyújtó filerendszer.

--
Sokan nincsenek tudatában annak, / hogy egyszer mindenki meghal. / Akik ráébrednek erre, / azonnal abbahagyják az ellenségeskedést.

Viszont a Journaling for FFS az előbb lesz, ha jól értettem az opensolaris? -ból akarják portolni a journaling kódot.

Solaris UFS (the same filesystem we call FFS) provides for a journaling filesystem with snapshots. Extend FFS/FFS2 similarly; it may even be possible to use a compatible on-disk format.

Üdv
Godot

Tudod vannak ilyen Linux kiddie-k, akiknek nem jó az UFS(2), így mindenáron valami divatfájlrendszert akarnak ráerőszakolni az OS-re.
Ami a FreeBSD-ből szerintem hiányzik az a ZFS, illetve valami clustering FS. Előbbiből talán lesz valami, utóbbival kapcsolatban nem hallottam semmilyen fejleményről.
Ehhez hozzátartozik, hogy a FreeBSD nem is igazán elterjedt (vajon miért :) vállalati körökben, így a cluster FS is kisebb jelentőséggel bír.

xfs-nél eddig jobb, rugalmassab, enterprise környezetbe használhatóbb fájlrendszert linuxra még nem találtunk. (Mondjuk ebben az is benne van, hogy mysql-el se szeretünk szopni, ahol lehet, postgres-t használunk :-) )

S még mindig benne van az a bug, hogy ékezetes filenév esetén sig11-gyel beledöglik oly szinten, hogy onnan max. Kürt úrék bányásszák le az adataid? :)

---
pontscho / fresh!mindworkz

Szerintem meg nem ez volt a kérdés. :D Leírom újra: amióta átformáztam Ext3-ra, azóta stabil, 250+ napos uptime-okat produkált. :) XFS-sel kb. hetente-pár naponta megdöglött és a szervízproci watchdogja resetelte ki mindig.

A MySQL-t nem dobhattam ki, mert kell az ügyfeleknek, ellenben az nem érdekel senkit, hogy milyen hiper-szuper-advanced-enterspájz filerendszer van alatta.

De lehet nyugodtan flémelni, már megszoktam. A debian-isp listán is megpróbált pár okostojás meggyőzni, hogy amiket leírtam, az meg se történt, hülye vagyok, rosszul láttam stb. :))))

Ide kívánkozik:

"Tilos utálni!
Muszáj szeretni!
Tilos utálni!
Muszáj szeretni!
Az XFS szép!
Az XFS jó!"

Pozsonyi Ádámtól elnézést kérek. :))))

--
Sokan nincsenek tudatában annak, / hogy egyszer mindenki meghal. / Akik ráébrednek erre, / azonnal abbahagyják az ellenségeskedést.

LVM alatt hasznalok XFS-t, kb 3 eve egy gepen, pusztan azert mert az elodom is ezt hasznalt, igy vettem at es hagytam. Sot azota ujratelepites is volt (vas csere miatt, nem file-rendszer hiba :) ) es maradtam az XFS-nel.
Elottem is ment 2-3 evig igy a gep, szoval jo 5-6 eve nem volt vele igazan baj, pedig azota mar jott ki egy ket uj kernel verzio, sot egy LVM verziovaltast is megeltunk. (LVM -> LVM2) Eleinte meg patch-elt 2.4-es kernelekkel ameg nem volt benne a main-ben az XFS, azota csak "siman", mostanaban mar 2.6-ossal.
A gepen amugy van vagy 300 user aki rendszeresen beloginol, webmail-ezik, stb. Igazan extrem terheles nincs, de mindenbol egy kicsi. Postgres dolgozik talan a legtobbet egy webes alkalmazas miatt, van Mysql is, de azon most asszem semmi nem megy, amugy Apache, ftp, samba, meg leginkabb a userek ssh-ja, scp-je.
Az XFS hibara visszavezetheto hibara nem emlekszem (velem bizots nem volt es elodomtol sem hallottam).

Nem vagyok file-rendszer guru. Ahogy irtam itt sem fanatizmusbol, inkabb csak hagyomanybol hasznalok XFS-t, mashol altalaban az egyszeruseg miatt az EXT3-at valasztom.

Sajnalom, hogy a temaban jellemzoen csak flame-et lehet olvasni. Valoban kivancsi lennek mar egy osszehasonlito irasra, akar a felepitesrol, akar a teljesitmenyekrol.

Ha valakinek van otlete, hogy mivel gurnyaszthatnam meg a file-rendszert, par teszt otletet szivesen varok. Az ekezetes file-nev pl eddig nem jott be ;) de ha 3 soros mysql magic scripted, vagy barmilyen otleted van azt szivesen fogadom.

Az "rm -rfv /" rosszat tesz neki, azt tudom, azt mar kar javasolni. ;)

Es egy konkret kerdes. Melyik file-rendszert lehet es nem lehet online meretezni? LVM alatt nekem nagyon kenyelmes, hogy az XFS particiokat lehet novelni (de csak novelni), mikozben fel vannak mountolva. Ha jol remlik (de ne kovezzetek meg ha tevedek) az ext2/3 ezt regebben nem tudta. Most mi a helyzet? Es a tobbi filerendszer?

( godot v | 2006. 06. 12., h – 10:14 )

De hát van natív 64 bites filerendszer linux-hoz pl. az XFS.

Maximum Filesystem Size

For Linux 2.4, 2 TB. For Linux 2.6 and beyond, when using 64 bit addressing in the block devices layer (CONFIG_LBD) and a 64 bit platform, filesystem size limit increases to 9 million terabytes (or the device limits). For these later kernels on 32 bit platforms, 16TB is the current limit even with 64 bit addressing enabled in the block layer.

http://oss.sgi.com/projects/xfs/

Üdv
Godot

Nem értem, az XFS miért nem jó, holott a Debian Etch-hez is azt ajánlják:
Based on all testing done for this benchmark essay, XFS appears to be the most appropriate filesystem to install on a file server for home or small-business needs
http://www.debian-administration.org/articles/388

Ja, jó nagy marhaság amit belinkelt!:-)
Komolyan szánalmas anyag, legalább annyira mint a legtöbb program nyelvek közötti összehasonlítás is.
Valaki az ext3-ra "esküszik", van aki a reiser-re, van aki az XFS-re, stb. attól függően szivott-e már vele.
Én már szivtam mindegyikel.. nem mondanám, hogy az ext3 a király.. se azt hogy a többi.
Fri.

Igen, elolvastam.. bár az is igaz kutyafuttában.
1. Vegyük az elsőt: physical vs. logical block journalling.. én megkérdezném a XFS fejleszetőket, hogy vajon ugyanazt a blokkot irják felül egy modositaskor?
2. aki olyan gépet üzemeltet UPS nélkül, aminél fontos az adatbiztosnság vessen magára..
3. volt ott egy szöveg a htree-röl/btree-ről.. ahol van egy másik szempont is. Nevezetesen egyik, hogy mennyi idő alatt tér magához a fs egy crash után (ha egyáltalán magához tér).. nos egyik ismerősőm csinált egy ilyen tesztet.. azóta használ xfs-t.

Végezetül meg csak annyit, hogy mindenkinek van személyes tapasztalata, ami szerintem jobb az ilyen teszteknél.. én már vesztettem el adatot (sőt egész lemezt) ext3 fájlrendszer alatt,
nem is egyszer, reiser és xfs alatt, amióta használom (kb. 4-5 év)
nem.

Ugyhogy ezért marhaság nekem ez a blog.

Fri

> 2. aki olyan gépet üzemeltet UPS nélkül, aminél fontos az adatbiztosnság vessen magára..

Ket szot mondok: freeze, es/vagy notebook.

(mikor mar 14-edszerre irodott felul 0x00-val az O_RDONLY megnyitott /sbin/cardmgr a csodas, gyors, megbizhato reiserfs alatt, inkabb vettem egy Macintosh-t. Unexpected leallasok itt is vannak, de egyresz joval kevesebb, masreszt HFS+ alatt 0 db fs corruption eddig masfel ev alatt.)

Linux, mert megerdemled.

Hat az teny, hogy a reiser hibaturese nagyon rossz. :-(

Most eppen egy ilyen gepet probalok itthon helyrepofozni, mert reggel megint elszallt rajta a bind zonafajlja. Ez az utolso gepem amelyiken meg reiser van es mar a harmadik eset, hogy ugyanezert kell reggel cifra karomkodassal inditanom. Az egy dolog, hogy apro fajlokkal gyors, csak a fene akar vele kinlodni.

---------------------
Ригидус а бетегадьбол

No én meg egy sorral válaszolok:
akinél ez 14x megtörténik és ezért OS-t vált, az megérdemli.:)
Ha meg freeze-t elismerem, pont olyanok miatt feküdt meg ext3-mal
nekem és pár ismerősőmnek is a destopos gépe..
Bár az is igaz, hogy lassan be kellene tennem a gépem a frigóba, mert ez a mocsok nem általott még azóta freeze-zni, ugyhogy gyanus!:-)
Szóval minden hit relativ.
Fri

Most már biztos vagyok benne, hogy nem olvastad....
Mert konkrétan ez nem egy teszt. Ez egy elméleti fejtegetés a PC-kről, a power fail interrupt hiányáról, és az ebből fakadó esetleges gondokról.

A végkövetkeztetés meg annyi, hogy valamivel biztonságosabb az ext3 az áramkimaradások esetén PC-n. (gy.k.: ha nincs áramkimaradás, esetleg nem PC-t használsz, akkor ez mind nem számít.)

Legközelebb talán olvasd el mielőtt véleményt mondasz...

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee."
-- Ted Ts'o

Egy helyen használtam a teszt-szót erre a blogra (elismerem rosszul) érdekes, hogy pont ezt láttad meg. Olyan vagy mint az a félszemű kinai az egri váras story-ban.. vedd észre máskor a többit is. Költői kérdés.. az ujjamból szoptam netán, a psychikai-logia, htree/bree-t? Olvasd el ismét a blogot, hátra ráakasz ezekre.. és utána gyere azzal, hogy ki mondjon véleményt bármiről is.
Fri

Már ne is haragudj, de ha olvastad, akkor hogy beszélhetsz személyes tapasztalatokról, meg arról, hogy te hol vesztettél adatot.

Az a rohadt e-mail semmi másról nem szól, mint kielemez egy adott esetet, nevezetesen a falból kirántott tápkábelt PC-n.
Ebben az egy esetben biztosan jobb az ext3 már elméleti szinten is, és erre nem cáfolat senki tapasztalata.

Persze ha leteszteled a Reisert, az XFS-t, és az ext3-at úgy, hogy rendszeresen IO művelet közben kirántod a tápkábelt, majd készítesz egy összehasonlítást, lehet, hogy kiderül, hogy ez mégse akkora probléma, de még ekkor is ami az e-mailben van, megállja a helyét.

"Ja, jó nagy marhaság amit belinkelt!:-)"
Ha így van légyszíves oszd meg velünk a cáfolatot.
Segítek:
Lehetséges támadási pontok:
- Nem igaz az, hogy nem egyszerre állnak le a gép részegységei vagy még ekkor sem kerülhet random adat a lemezre.
- Nem igaz az, hogy a PC-n nincs power failure interrupt
- Nem igaz, hogy úgy működnek az említett filerendszerek, ahogy ott le van írva...

Kérlek mesélj, hogy tanuljunk valamit!!!

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee."
-- Ted Ts'o

Hogy beszélhetek személyes tapasztalatokrol? Elég bugyuta kérdés.. csak nem inkonzisztens állapotba kerültél? Ugyanis akkor ilyet nem tennél fel.. fsck-t probáltad már?:)
A kedvedért.. ugy hogy nem értek egyet ezzel az "elméleti szinten is biztosan jobb néphülyítéssel) gyakorlati szinten.. ezért is irtam (egyrészt), hogy nagy marhaság, mert egy dolog az elmélet, és egy másik a valóság/tapasztalat.. többek közt a személyes tapasztalat.
Ha valaki párszor befürdik egy fs-el az valószínű nem fog elhinni minden "mesét".. föleg akkor nem ha az egy überfürer tipusú.
Az elméleti tényekkel nem lehet vitatkozni:
- igaz, hogy nem egyszerre állnak le a gép részegységei
- igaz, hogy a PC-n nincs power failure interrupt
- nem tudom, hogy biztosanúgy működnek az említett filerendszerek,
ahogy ott le van írva...
A gyakorlati tények meg a következők (a részemről):
- kb. 4-5 éve kétszer szállt el mindennem menet közben (csak ugy, nem volt semmi power off) ext3 alatt (és még két kollégámnak)
- aki igy elméleti szinten boncolgatja a kérdés-t, ugyan tegye már hozzá, hogy mi van a winchi-ben található cache-vel, ha hardweres raid-et használsz annak a cache-vel és még sorolhatnám a finomságokat, amik power off-nál keresztbe tehetnek az "elméletnek", de nyilván ezeket nincs ember aki bele tudja számitani az "elméletbe"

Föntebb olvasod: a ficko 14x probalkozott es utana OS-t valtott, en 2x utana fs-t valtottam, volt raiser, most xfs, de nem lettem se reiser, se xfs hivő.. viszont itt olvasva a hozzászolásokat, a sok lama ext3 hivő tömörödött össze, holott:
- mikor kijott sokan nem is tartották igazi naplózó fájl-rendszernek, csak egy uj börnek az ext2-n
- mikor kijött anno az ext3, bizony messze nem volt elég stabil, de elhiszem, elfogadom, hogy már kikupálodott
- kernelenként, architekturánkánt, hardwerenként, alkalmazásként, szököévenként változik/változhat egy fs megbizhatósága/teljesitménye

De hogy tanulj is valamit: az egyiptomiak ékirását wazze még 2000 év mulva is olvasni fogjak, de hol lesz akkor az ext3, meg a többi marhaság, amin most vitatkozunk!:-)
Na erre mond valami okosat!:-)
Wazze!
Fri

"a sok lama ext3 hivő tömörödött össze"
"az egyiptomiak ékirását wazze még 2000 év mulva is olvasni fogjak, de hol lesz akkor az ext3, meg a többi marhaság, amin most vitatkozunk!:-)
Na erre mond valami okosat!:-)
Wazze!"

:)
Ne haragudj erre már nem tudok mit mondani. Ennél okosabbat...

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee."
-- Ted Ts'o

Saját (nem reprezentatív mintának számító) tapasztalataim nagyjából megegyeznek a tr3w-féle írás tartalmával:
- bizonyos esetekben az ext3 lassú, a Reiser gyors (NFS-sel együtt azonban felejtős a Reiser)
- nagy átlagban viszont nincs különbség a kettő között
- mióta az ext3 kijött, soha nem tapasztaltam vele komoly adatvesztést (legdurvább eset egy /var/run-beli ideiglenes fájl elvesztése volt egy olyan gépen, amelyiket minden egyes alkalommal tápkihúzással kapcsoltunk ki)
- ismerek eljárást, amelyikkel 100%-osan generálható ReiserFS adatvesztés, és amelyikkel előbb-utóbb fájlrendszer vesztés is megfigyelhető (Valamilyen bugos driver-rel, vagy szánt szándékkal kernelhalált kell csinálni, a kernelhalál után következő reboot során a Reiser a napló alapján hibásan fogja helyreállítani a le nem zárt fájlokat. Külön kiemelem, hogy a módszer determinisztikus: nem a kernelleállás során keletkezik a hiba, hiszen nem is történt tápkirántás, a HW tökéletesen müxik tovább, csak a vezérlése szűnik meg hirtelen. A hiba a következő, normális körülmények közötti rebút során történik.)

( bra | 2006. 06. 12., h – 10:15 )

Wow. Nemrég formáztam UFS2-re egy 256 TB-os fájlrendszert... :)

Nem. Valami olyasmi megoldasrol hallotam hogy a gep osszes eroforrasat csak az fsck ra forditani es igy ugy hallotam par perc a dolog de kozbe a gep *semmi* masra nem hasznalhato. De mondom ezt csak hallotam ugy fel fullel es en nem is ertek hozza. Nem vagyok vfs guru :). Bra szerintem 64 bit LBA es superblock van.

Normál rendszerinduláskor foreground fsck esetén így sem használható semmire.
Egyébként az fsck-nál tapasztalatom szerint a diszk IO is elég limitáló. Nekem úgy, hogy csak az fsck futott induláskor a régi ftp.fsn.hu 1 TB-os diszktömbjének fsck-zása kb. 1 óra volt...
És ez még nem is nagy fájlrendszer.

Tudsz esetleg linket adni erről a beszélgetésről?

( GegSite | 2006. 06. 13., k – 00:30 )

Ha már fájlrendszer felvarrás.
Lenne egy ötletem ami szerintem nagyon hasznos lehet, és egy kis helyet is megtakarithat.
Arra gondoltam hogy miért ne lehetne olyan fájl ami hivatkozna egy másik fájl adott részére. Pl. az alma.jpg valójában a gyümölcsök.pdf vagy a gyümölcsök.tar.gz ben található egyik képre hivatkozva. Ez azért lenne jó, mert nem kéne 2x helyet foglalni a képnek, hanem egy kis hivatkozó fájl segitségével lenne elérhető. Olyan lenne mint a htm nél a bookmark, egy virtuális fájl ami egy valós fájl egy része lenne. Pl. egy munkalapra egy táblázatból stb.

Remélem valahogy eljut egy fejlesztőig az ötlet (és majd a microsoft jól ezt is ellopja az új fájlrendszerébe, hogy ezt Ő találta ki).

Nagy Gergő