ext4 a "legjobb" linux fájlrendszer?

Naplózó filerendszerek (journaling)

érdemes új winchesterre ext4 fájlrendszert feltenni?
általában reiserfs volt amit használok. eddig meg voltam elégedve vele. bár a BKL néha zavaró. kérdés, hogy 1Tb méretű partícióknál is optimális e még? vagy inkább ext4? esetleg jfs? vagy xfs?
régebben használtam xfs fájlrenszert is. remek olvasási teljesítményt nyújtott, a fájltörlés viszont lassú volt. a nagyobb hibája pedig az volt, hogy nagyon rosszul tolerálta az "áramszünetet" és a "takarítónénit":)

  • 26948 megtekintés

( mhmxs v | 2010. 03. 28., v – 09:34 )

Hát konkrét felhasználási terület meghatározása nélkül nehéz lesz erre a kérésre mit mondani. Mindenesetre a héten raktam fel pl egy netbookkra linuxot, ezt megolvasva úgy döntöttem ext4. Plusz mint írtad xfs nem tolerálja a hirtelen leállást, ami egy mobil gépen azélrt előferdül, a reiserfs fejlesztése már nem annyira aktív (fixme), ezeket gyorsan elvetettem. Az ext4 ha minden igaz jobban teljesít mint az ext3, de mint az elején írtam a konkrét feladat ismeretében nehéz okosat mondani.

java'nother blog

Csak négy hibát találtam:
Nagy H-val kell kezdeni, rövid ü, egy j és az is ly. :-)
A többi stimmel.

És ráadásul szétoffolod a topicot. :-)

Hogy valami on is legyen:

Mit tudtok, az UFS2 filerendszer támogatása hogy áll éppen a Linux kernelben?

FYI: ezek szerint csak kis hűjje az illető? Én azt is belekalkuláltam ám, hogy itt mindenki végletesen hűjjéz le mindenkit :-)

Igen, ezt láttam én is. Be lehet állítani kernel fordításkor, hogy írni is lehessen. A kérdés inkább olyan irányú puhatolózás volt, hogy kísérletezett-e már ezzel valaki... (értsd: inkább más szenvedjen vele, mint én :-) ).

1 eset: A vadi új gép (netbuntu 9.10) távollétemben szól, hogy le fog merülni, majd sleepre teszi magát, de akkor is sleepre teszi magát ha 15 percig nem nyúlok hozzá. Később visszajön a paraszt, azaz én, feléleszti a gépet, _igenám_ de a rendszer legközelebb már nem nyavajog, egész egyszerűen kikapcsolja magát (épp tegnap tapasztaltam ezt a dolgot).
2 eset: A notimon 2 vagy 3 év használat után egyszercsak megszünt az a feautre, hogy az oprendszer valós képet kap az aksi állapotáról (tudom vehetnék új aksit, de _szinte mindig_ hálózati töltőről használom), ebből egyenesen következik, hogy a már egyébként is megfáradt aksi olykor lemerül 15-20 perc alatt és erről még csak szólni sem bír így a gép egész egyszerűen kikapcsolja magát. Namost ha ezzel a hibalehetőséggel nem számolok már most, akkor 2-3 év mulva rakhatom újra a gépet, ami nem nagy szám, de minek, ha jelen esetben a hibatűrő fájlrendszer választásával elkerülhető.

java'nother blog

A reiserfs-t tudtommal meg fejlesztik, vagyis legalabbis karbantartjak, szoval nyugodtan lehet hasznalni. En nagyjabol mindenhol ezt hasznalom idetlen idok ota, es meg semmilyen problemam nem volt vele. Az ext-eket nem szeretem, az XFS-sel meg tul sok a szivas, raadasul tulsagosan memoria-intenziv nekem.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

mivel ma is része a vanilla linux kernelnek, szerintem is nyugodtan lehet használni. nem fog arra a sorsra jutni, mint a xiafs vagy az ext1 fájlrendszer a linux történetének korai szakaszában. ha ma hivatalosan támogatottá válik egy fájlrendszer, akkor az is marad a jövő kerneljeiben is.
a kérés inkább az, hogy melyik az optimális választás ma 1TB partícióméretnél?

hát elsőre természetesen egy otthoni mindenes computer. fejlesztés/fordítás, film/zene, mellette nas a többi computer számára, néha videodigitalizálás, videoszerkesztés, zimbra webmail rendszer egy virtuális gépről... ilyesmi.
ha beválik, gyors és megbízható is, mehet a serverekre is ext4, vagy esetleg jfs vagy xfs.

jfs egyesek szerint inkább scsi winchestereknél jó, sata/atanál nem optimális.

( arpi_esp v | 2010. 03. 28., v – 09:44 )

En nagyon varom mar a btrfs-t. Az ext* sose jott be, reisert hasznalok.

XFS nagyon gaz, az enyhe kifejezes hogy nem toleralja a szabalytalan leallast, kisebb disk hiba (raid0-bol kiesik 1 vinyo kabelhiba miatt) eseten annyi az adatok 80%-anal. Tapasztalat. Tobbszor.

A'rpi

ennyire nem vagyok hulye...
kiesik alatt azt ertettem, hogy van egy felmountolt rw xfs raid0 tombrol, es a szar sata tapdugo kontakthibaja miatt egyszercsak disconnectel az egyik disk. gep kikapcs, kabel kicserel, bekapcs es ott van ujra minden disk. de az xfs nem mountolodik (vagy igen de csomo konyvtarba nem lehet belepni), xfs_repair tobb orai kemeny munkaval eltunteti az adatok 80%-at, alig marad valami hasznalhato, es ott se mindig az a file tartalma ami a neve (osszekeverdnek az inode-ok).

de sima mezei aramszunetet se usztam meg meg xfs-nel data loss nelkul.

A'rpi

de nem veglegesen esett ki a disk (amikor tenyleg nem sok marad az adatokbol fs-tol fuggetlenul), hanem csak ideiglenesen.

nem volt "teljesen véletlenül" bekapcsolva a write-cache abban a diszkben? mert ugye tudod, hogy hova távoztak azok a bitek, amiket a write-cache miatt visszaigazolt a diszk az os-nek, de áram már nem maradt a diszkre íráshoz?

nyilvan be volt kapcsolva, meg volt meg nehany irasi probalkozas is a disk kieses utan. azt meg is ertenem ha mondjuk az utolso 10 percnyi iras elveszett, talan meg azt is, ha azok a konyvtarak ahova iras tortent, na de az adatok kb 85%-a??? olyan dir-ek is amihez fel eve nem volt nyulva...

mas filerendszereknel sose tapasztaltam ilyen szintu adatvesztest.

A'rpi

a metaadat változtatások írása a logba történik, melyből egy darab van per filesystem. create/delete, meg ehhez hasonlók műveletekről beszélünk, ezeket írja sorfolytonosan oda.

melynek random blokkjait egy random tartalmú korábbi verzióval "felülírtad".
ezek után a legközelebbi alkalommal a "hülyeségeket" amik a felülírt blokkokba kerültek (create/delete meg hasonló műveletek) a filesystem végre is hajtotta. te meg meglepődtél.

ha a fenti raid0-ás műveletet egy oracle adatbázissal játszod el, akkor ő simán észreveszi a minden adatbázis blokkban levő checksum alapján. és közli veled, hogy akkor most vegyed elő a backupodat, mert megsérült a diszken az adat, és gyakorlatilag kuka az adatbázis.

a probléma lényegi része, hogy minden valamirevaló filesystem elvárja, hogy ha az 1-es blokk kiírását visszaigazolta a diszk, majd ezután a kezdeményezi a 2-es blokk írását, akkor semmilyen áramszünet esetén nem elfogadható, hogy a 2-es blokk kikerült a diszkre, de az 1-es meg nem. ezen feltétel biztosítása nélkül nem lehet értelmes journaling fs-t írni. az egy szimpla mázlifaktor pl., hogy az ext3 cache flush algoritmusa mellett ez a szituáció ritkán okoz hasraesést. de ott sincs kivédve, csak ritkább a szívás.

igen ilyesmire tippeltem en is. vagy ajar az inode tablakban irkalt at de csak az atiraosk egy resze kerult ki tenylegesen a diskre.

ami viszont gaz, hogy
- ha 1 disk kiesik raid0-bol, akkor a linux kernel miert nem off-olja az egesz tombot azonnal?
- ha 1 disk hianyzik akkor oda biztosan nem lehet irni (a write cache is a vinyoban van igy az se elerheto) akkor miert folytatja a filesystem a mukodeset? miert nem all le hibaval? (na jo ez koltoi kerdes volt, tapasztalatom szerint a linux fs-ek tobbsegeben az alacsonyszintu i/o hibakezelese mint olyan nem letezik, ilyen esetekben elobb utobb elcrashel a kernel, ahelyett hogy az fs driver kiirna hogy he pajti nem irhato a disked! valtsunk readonlyra vagy ilyesmi. bar gondolom ennek egyreszt teljesitmenybeli oka van, masreszt aszinkron i/o (NCQ stb) eseten ill. i/o utemezok miatt nem is lehet azonnal tudni hogy sikeres volt-e a muvelet)

A'rpi

Az ext3-ban van már write barrier támogatás, ami a barrier=1 mount opcióval bekapcsolható. Más kérdés, hogy nem küszöböl ki minden problémát. Ráadásul csak akkor működik, ha az ext3 rétegtől "lefelé" egészen a hardverig bezárólag minden réteg támogatja ezt a tulajdonságot. Úgy tudom a device mapper réteg csak 1-2 formátumnál - pl. RAID1 - tudja, úgyhogy szívás. Ami a checksum-ot illeti, az ext4-ben van már az is.

( nanto | 2010. 03. 28., v – 10:23 )

En ext3 parti vagyok, es meg nagyon sokaig az leszek. Azt mindennel fel lehet csatolni, helyreallitas szempontjabol legkiforrottabb. ext4-ben hatalmasat csalodtam, mikor fedora csak maganak tudta felcsatolni aztan rescue discen maganak se (direkt nem volt lvm se). Vegul kiderult, hogy a vinyom volt erosen bad sectoros, de pont az lett a szimpatikus, hogy ext3-at a fold alol is elo lehet hozni. Ja meg volt egy 400-asom ami pillanatokra elvesztette a sata jelet, de akar menet kokzben jott a widget, hogy felcsatlakoztattam, es vissza tudtam mountolni. legalabb 30 ilyen sudden stop utan gond nelkul mukodott.

Tehat en adattarolasra is ext3 parti vagyok es rendszerre is, az a legtszteltebb, legkiforrottabb, katasztrofalis allapotu vinyon is szepen elmegy, az meg nem zavar, hogy ha masolhatnek 70MB/seccel es csak 55MB/seccel tudok. Valknut igy is behashelt 20 perc alatt 100 Gigat, ntfsen meg 400 giganak nem volt eleg egy este 8-tol reggel 9-ig peridous+nem ment kozben film a amsik szobaban, amig olvasott.

--------------------------------------------------------------------------------------------------------
A Windows 7 fejlesztoiben felmerult a kerdes, hogy belerakjak a kde 3.5.10-et. De Bill Gates ezt valaszolta: "Majd ha fagy"

"ntfsen meg 400 giganak nem volt eleg egy este 8-tol reggel 9-ig" ezt ugye nem windows alatt tette ?
Tapasztalatom szerint a ReiserFS adja desktop környezetben a legkiegyensúlyozottabb teljesítményt.
Ext3-nak viszont valóban jobb a hibatűrése.
Ext4-nek kell még egy kis idő.
A btrFS-t én is várom.

Valoban ntfs-3g alol tette linuxon, de egy masik pelda: wine+heroes 3, rakattintok a single playerre akar windowson akar linuxon, csomo ido volt, mig betoltotte 1700 palyanak az adatait (linuxon talan 1-2 seccel tobb). Atdobtam a Heroes 3-at ext3 particiora, es ott wine alol fele annyi ideig se toltotte be a map file-ok elejet, mint win-en ntfsen.
Egyebkent egyetertek, ext4 3-4 ev mulva nekem is megfelelo lesz szerintem, reiserfs jfs xfs nekem meg azert nem jatszik, mert nem annyira default, nem annyira elterjedt, igy felek, nem olyan kiforrott a hibajavitasa. Azert a par MB/secert meg nem kar nekem

--------------------------------------------------------------------------------------------------------
A Windows 7 fejlesztoiben felmerult a kerdes, hogy belerakjak a kde 3.5.10-et. De Bill Gates ezt valaszolta: "Majd ha fagy"

Pedig igy volt. Midnen file-nak be kellett olvasni az elejet, es a zene alapjan hallhato volt, hogy hol tart. 1700 fajlnak olvass ki az elejebol egy tag-et: lathato lesz a kulonbseg, jobban, mint egy nagy file masolasanal. Azt viszont elismerem, hogy ahol a linux tud 100MB/seccel masolni ext4-rol ext4-re, ott a windows is tud ntfs-rol ntfs-re minimum 90-nel, ha kiurited a tudatat, de azert az ext3 szerintem egy elegge atgondolt fajlrendszer, joval tobben dogloztak rajta mint az ntfsen (es azon tenyleg dolgoztak, kellett a komolyabb szerverekhez is, ellentetben a legtobb nyilt forrasu projekttel).

--------------------------------------------------------------------------------------------------------
A Windows 7 fejlesztoiben felmerult a kerdes, hogy belerakjak a kde 3.5.10-et. De Bill Gates ezt valaszolta: "Majd ha fagy"

"Azt viszont elismerem, hogy ahol a linux tud 100MB/seccel masolni ext4-rol ext4-re, ott a windows is tud ntfs-rol ntfs-re minimum 90-nel"
Ezt most megmérted vagy csak találgatod ?
Nekem elég sok mérés alapján más a tapasztalatom.
Az Ext-ek közül másolásban az Ext2 a leggyorsabb de a legbutább is egyben.(nincs journaling)
Nagy fáljok esetén az NTFS elmaradása 1-2% akár a mérési pontosságon belül.
Sok apró fálj esetén gyorsabb az NTFS 6-7%-kal.
A raw írásnál mid két FS 15-18%-kal lassabb.
NTFS-nél ráadásul választhatsz tömörített file redszert , növelve az átvitel sebességét a CPU load rovására.

A minimum 90-be belefert az eredmenyed :) Meg olvasas != iras, a Heroes 3-asnal csak olvasni kellett, bar ennek ellenere is meglepo az ellentetes meresed, miszerint még az ntfs gyorsabb apro file-ok irasanal. Bar lehet volt az ntfssel mas baj is (pl toredezettseg), mert regota meglevo volt, az ext3 meg tok friss
Meg nekem volt egy noname vinyom (Excelstor asszem) ami 10MB/seccel irt ntfs-re nagy file-t, es 800kB/sec korul kis apro file-okat (regen volt még AMD Sempron 939 idejeben), de ott nyilvan a vinyo volt hulladek pl.

Ennek ellenere szerintem az ext* filerendszerhez 1000x annyi szakerto nyult, mint pl egy amarokhoz, azon nyilt forrasu dolgok egyike, amik tenyleg meg vannak csinalva, mert a legkomolyabb linux-felhasznaloknak (szerver szinten) is erdeke. Es ezt nem fogja szerintem utolerni egy ehhez kepest keves, kizarolag MS-nek dolgozo programozo NTFS-projektje. hangsulyozom, hogy ez a legtobb projektnel nincs igy.

--------------------------------------------------------------------------------------------------------
A Windows 7 fejlesztoiben felmerult a kerdes, hogy belerakjak a kde 3.5.10-et. De Bill Gates ezt valaszolta: "Majd ha fagy"

ez mondjuk lehetseges, de illene neha atnevezhni azt a szerencsetlen projektet akkor mar, es valoban nem Win7-es ntfs-sel probaltam. Ennek ellenere a mai napig katasztrofalis az osszes Windows-telepito particionalo felulete is pl.

--------------------------------------------------------------------------------------------------------
A Windows 7 fejlesztoiben felmerult a kerdes, hogy belerakjak a kde 3.5.10-et. De Bill Gates ezt valaszolta: "Majd ha fagy"

Az "open-source" és closed-source rendszereknek van annyi eszük, hogy a "unix-szabvány" ufs-t használják, egyedül a binux olyan, aminek _mindenképp_ össze kellett hugyozni egy sajátot. A többi normális Unix pont emiatt a felesleges különcködés miatt szarja le az ext2-t, a Linux meg ugyanezért a saját nevetséges különcködéséért teszi a szabvány filerendszerrel ugyanezt.

De te case-sensitive filerendszerekből diplomáztál, úgyhogy ezeket tudnod kéne ;)

[ Like ]

feltéve, hogy az egymás formátumát elolvasni képtelen, ámde nevükben megegyező fájlrendszereket egyformának tekinted.

a valóság ezzel szemben az, hogy semelyik kommerciális unix nem olvassa a másik standard fájlrendszerét; vehetsz pénzért külön veritas vxfs-t, az megy n különböző oprendszeren, és akkor el tudják olvasni egymáséit.

pl. megnézem, hogy egy default (-o logging) solaris 7-8-9-10 ufs-t mikor olvas el egy akármilyen *bsd, hiába nevezik pont ufs-nek ott is a fájlrendszert...

Nemtom, én a múltkor mountoltam Digital Unix-os fs-t NetBSD alól, és közvetlen futtattam a binárisait. Vagy csak az LSD mondatja ezt velem? :)

nem ultrix volt "véletlenül" az a digital unix? ;-)
mert nem hallottam róla, hogy az advfs-t portolták volna netbsd-re... mellesleg, ha nem lenne gpl-fóbiájuk, akkor akár portolhatták is volna - nem mintha sok értelme lenne. az ufs driver tuti nem olvassa el az advfs-t.

Modernebb interoperabilitáshoz pedig nem kell Veritas, elég egy ZFS. Bár a linux ugye ebből is kimarad :D

dehát zfs nincs szinte semmire (és nem is nagyon lesz), abból nem lesz interoperabilitás...


> nem hallottam róla, hogy az advfs-t portolták volna netbsd-re

ufs-ről volt szó...

dehát digital unixon senki nem használt ufs-t az elmúlt ~15 évben.

> dehát zfs nincs szinte semmire (és nem is nagyon lesz)

Végülis ha a Solaris, FreeBSD, NetBSD, OS X semmi, akkor tényleg :)

hát, kb. "szinte semmi". :)

az os x-port, az igazából nincs. end-of-life emlékeim szerint. ha az apple nem csinálja meg (márpedig szemlátomást leszállt róla), akkor más sem fogja.

a solarishoz képest ez egy freebsd + egy netbsd (nem tudom, hogy ezek mennyire működnek, ennyire nem foglalkoztam velük sosem), hát az kb. a szinte semmi.

egyetlen másik (még futó) kommerciális unix-ba sem fog belekerülni; ha a linuxba be tudna kerülni, az talán még jelentene valamit, de tudjuk, hogy ez sem fog bekövetkezni.

"az os x-port, az igazából nincs."
read only támogatás van egy ideje.
arról volt szó, hogy a rendszerek tudják-e egymás fájlrendszereit olvasni.

egyébként miért lenne szempont, hogy a rendszerek tudják olvasni egymás fájlrendszereit, mikro manapság 1-2 ezer Ft egy gigabites hálókártya, s pl. nfs megosztás 1 perc...

arról volt szó, hogy a rendszerek tudják-e egymás fájlrendszereit olvasni.

eléggé fura, hogy opensource rendszerek között problémát jelent egymás filerendszerének a kölcsönös és fullos támogatása.

itt kezdődött ez a legutolsó "szösszenet".

szerintem nem "eléggé fura", hanem abszolúte reális. irreális, hogy a szükséges energiát beleöljék egy readonly-nál többet tudó, másik os fájlrendszerét támogató kódba. egy-az-egyben meg nem lehet berakni a másik kódját, még ha véletlenül a licensz meg is felelne (ahogy sokszor az is akadály).

ez meglep. még captiveNTFS driverrel csak érteném, de ntfs3g... imho más probléma is lehet ott.
nálam még akkor is masszívan 10MB/s felett van az írási sebesség, ha már dugig tele van az ntfs partíció, inkább 20MB/s közelében. ráadásul ugyanazon a winchesteren levő linux partícióról másolva, és nem /dev/nullból írva.

"En ext3 parti vagyok, es meg nagyon sokaig az leszek"

+1. Ext4-gyel többször próbálkoztam, de mindig rejtélyes fagyások voltak alatta. Ext3 viszont eddig üzembiztos volt single vinyón, raid1, raid5, raid6 alatt. Áramszünetet is jól tolerálja.
Mindössze egyszer volt gondom az elmúlt 6 év alatt, az sem a fájlrendszer hibájából adódoan: desktop gépen egy rescue alkalmazás felülírta a partíciós táblám, de szerencsére a testdisk visszahozta.

( bounty v | 2010. 03. 28., v – 11:18 )

Érdemes. Pl. nekem otthoni desktop felhasználásnál ég és föld a különbség sebességben az ext4 javára. 1 éve használom, semmilyen problémám nem volt vele és pl. nagy fájlok törlésénél nagyságrenddel gyorsabb.

( Csigaa | 2010. 03. 28., v – 11:41 )

Engem is érdekel a kérdés, nagyobb upgrade-re készülök (Ubuntu 8.04 -> 10.04), és az új rendszerben már ext4 az alap.
A rendszerpartíció természetesen formázásra kerül, az tiszta sor, de az adatok ext3-n vannak.

Átalakítani lehet ext3-t ext4-gyé on-the-fly (á la ext2 -> ext3, ami még visszafele is ment)?

Probaltam atalakitani. Elszallt minden adat, pedig step-by-step kovettem a leirtakat hivatalos oldalon. Backupod mindig legyen. Nalam nem volt ra szukseg mert a kisgepen probalkoztam vele. (Aztan most mar XFS van mindenutt, gyorsabb mint ext4, s meg az adataim is megvannak nem ugy mint ott.)

HUP WIKI. http://wiki.hup.hu , bal oldalt meg beirod keresobe XFS. Ott legorgetsz, es megtalalsz mindent. Az is megy amit itt irtak felettem/alattam.

DE. Minden egyeb ami nincs emlitve a Wiki-n, opcionalis lehet. Tehat ha nem fog bebootolni/mountolni ugy, akkor allj wiki-sre. Erdemes leszedni kernel-docs package-t, majd meglesni az xfs doksijat, ott irjak miket tud az adott kernel. (Peldaul Fedora-n nem mountolt logbufs-al ha jol remlik. Meg topicot is nyitottam rola valamikor, csak mobilnettel nem akarom vegigturni a trackem.)

Nem ismertek free megoldást az alábbira?

"Hátrányai

* Törölt adatok visszaállítása (undelete) csak Microsoft Windows alatt futó kereskedelmi alkalmazásokkal lehetséges:"

------------------------------------------------
A legtöbb ember azt hiszi, csak a gyomra üres...

ext3/4 fsekhez még kereskedelmit sem ismerek. az xfs esetében ez még így is pozitívum, hogy legalább van. akkor is ha win+proprietary, a semminél több.
reiserfs esetén lehet szórakozni a
reiserfsck --rebuild-tree --scan-whole-partition partíció.image
paranccsal, célszerűen a backup image elkészítése után. szerencsére még soha nem kellett használnom.

( bambano | 2010. 03. 28., v – 15:33 )

Mivel a kimondott kérdésekre még nem látom a választ, szerintem ext2. Ext4-re volt itt panasz mostanában.

Miért is? gyakorlatilag nem tudjuk a felhasználás módját, célját, pont akkora esélye van, hogy beletrafálok az ext2-vel, mint a többi hozzászóló az ext3/ext4/xfs/reiserfs/stb. javaslattal. Nem tudjuk, hogy kell-e gyors boot, vagy gyors helyreállítás, semmit nem tudunk.

Célzásnak szántam, hogy mondhatna többet a célokról.

A journaling alap barmilyen felhasznalasnal. Nalam meg a /boot particio is ext3-as, noha oda nem surun van irkalva. Talan egyes-egyedul akkor lehet ellenjavallt a journaling, ha floppyt formazol ext3-ra - errol viszont nincs szo.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Ugyan.

Valamelyik több mint 10 évvel ezelőtt megjelent CHIP magazin CD mellékletéről telepítettem először GNU/Linux-ot (egy Red Hat disztrót), azóta semmi mást nem használtam, csak ext2-t. Kicsit pocsékolja a helyet, de nem vészes, elfogadható (250 GB-ből (a GB-t winchester-árusi mértékegységben értve) 230 GB (valódi GB) felhasználható). Stabil, kiforrott. Gyors is, különösen mióta elérhető benne a 

dir_index

, journal nélkül is (vagyis anélkül, hogy ext3-má kellene alakítani). Az évekkel ezelőtt bruttó 13e-ért vásárolt SATA diszkből kihoz kitartott 70MB/s szekvenciális olvasási és 63MB/s írási sebességet (beleértve az írás végső sync-jét is, egy 7.8 GB-s tesztfile-on).

2005 novemberében megnéztem az ext3-at, akkor a teljesítménye hideg zuhany volt. Az ext3 amúgy sem teljesen őszinte megoldás, ha nem 

data=journal

módban használják, úgy meg (állítólag) elképesztően lassú.

A reiser-ről (talán a v3-ról) azt olvastam, ha jól emlékszem, hogy ha az fs-ben tartasz néhány reiser fs image-et reguláris file-ban (loop-os használatra), akkor egy reiser fsck jó eséllyel a tartalmazó fs-be beleszervezi a file-ban tartalmazott fs-t. Ez nem igazán vonzott.

Egyszóval ext2. Nincs UPS-em, egy időben rengeteget fagyott a gép (ócska videokártya driver), magic sysrq sokat segített, volt egy-két áramszünet is; nem emlékszem, hogy vesztettem volna file-t. Van egy kialakult, növekményes mentési sémám (másik diszkre, szintén ext2, rdiff-backup-pal, kizárólag a mentés idejére rw, egyébként ro; illetve van off-site is). Az ütemezett fsck 100 csatolásonként fut, néhány percig tart, még jobban is érzem magam tőle, "na, mindent átnéztünk". Töredezettség elhanyagolható. 4 KB-s blokkmérettel a maximum file méret 2 TB, vagyis desktop-on gyakorlatilag végtelen. Bolond lennék váltani. Majd akkor, ha valamelyik extent-es (

posix_fallocate()

-et támogató) fs atomstabil lesz.

Ha sok apró file-lal kell dolgozni, akkor inode szám szerint rendezem a listát, és akkor lényegében nincs seek. A 

vfs_cache_pressure

sysctl-lel a memóriában tartom az inode és dentry cache-t, ez általában véve is mérsékeli a fejrángatást.

A FAT-tel pedig nyilván nem összehasonlítható; az ext2 egy rendes UNIX(R) filerendszer.

( Lacyc3 v | 2010. 03. 28., v – 23:25 )

Az ext4-el jók a tapasztalataim. Nem egyszer volt már, hogy laptopon az akku lemerült, az Ubuntu elaltatta, majd hírtelen kellett volna a gép, töltő persze nuku, elindul a rendszer félig (kerreg a vinyó) majd hírtelen lekapcsol a gép. Volt, hogy mentéseket másoltam át (sok 10GB) hordozható HDD-ről helyire, amikor elment az áram, az UPS fél órát bír, de legalább 1 óra kellett volna még a teljes befejezéshez. Merész voltam, kicentiztem, elfogyott a szufla.. zokszó nélkül indult az ext4 amikor visszajött az áram, a mentéseket elég volt a legutolsó előtt másolt állománytól újra másolni. Szóval belopta magát a szívebe.

Igaz, én sem mindig --delete kapcsolóval futtatom, de havi 1x legalább azzal.
Desktopon a biztonsági mentésben miért legyenek ott a rég letörölt fotóim?
Szerveren a biztonsági mentésben miért legyenek ott a user rég elfeledett és letörölt levelei?
Ha gáz van, emberi időn belül csak észreveszi az ember és akkor visszaállítja. Nem kell hosszú hónapokig örködni mindenen. Bár lehet, hogy csak szokás kérdése. Én szeretem a backupot is ilyen formán rendben tartani:)

En most szivom a fogamat, mert ket ev utan igencsak hianyzik a letorolt oneletrajzom tex forrasa. Szoval a franc tudja, desktopon, otthoni felhasznalasra en ellenjavalltnak tartom a --delete kapcsolot. Munkahelyen pedig policyje valogatja. Ha penzugyi helyen dolgozol, akkor koteles vagy mindent 5 evig megorizni, amiben a forint szo megtalalhato.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

( Lightning | 2010. 03. 29., h – 18:13 )

Három adatlemezen is használok ext4-et, amiket ext3-ról konvertáltam.
Fogjuk rá, hogy desktop körülmények közt... :) Lényeg, hogy hibamentesen teljesítenek.
Szinte semmi különbséget nem látok az ext3-hoz képest, talán ipari mennyiségű kisebb fájllal való műveleteknél gyorsabb.
A rendszert viszont nem volt még merszem upgradelni. Majd egyszer 64 bitre váltással együtt...

( prygme | 2010. 03. 31., sze – 04:54 )

érdemes a "huge_file" opciót "large_file"ra változtatni az "ext4" blocknál az /etc/mke2fs.conf fileban?
illetve mkfs.ext4 -O large_file /dev/sdc1
parancssori opcióval létrehozni az ext4 filerendszert?

a huge_file új lehetőség az ext4ben jelent meg, 2TB méretnél nagyobb fájlok használatát teszi lehetővé. de mivel jelen esetben 1TB méretű partíciókról van szó, gyakorlatilag ennek semmi haszna nem lenne. talán még gyorsabb is lehet valamivel a filekezelés, ha "csak" large_file van aktiválva, lassabb imho biztosan nem lehet tőle.

( crown v | 2010. 03. 31., sze – 13:40 )

Kisuzemi felhasznalas eseten (nem celiranyos, extrem felhasznalasra) en mindenkepp ext4-at hasznalnek. A teljesitmenye turheto. xfs es reiser is kepes jobb lenni, de elobbi nem hibaturo, utobbit nem igazan kedvelik a rescure rendszerek ill. en nem biznak benne mr. reiser rossz hirei utan ;) /de ez szubjektiv/

ami tetszik az ext4-ben, hogy relative kis felhasznalasra is optimalisan tud mukodni, es eddig nem volt vele igazan komoly bukta. [ellenben a tobbi, high performance file rendszerekkel]

( dash | 2010. 04. 01., cs – 16:36 )

subscribe

---
Ami a windowsban szarrágás, az linuxban hegesztés.
Ha megszeretted a windowst, tanuld meg használni!
A linux igenis felhasználó-, és NEM idiótabarát.
A linuxot mi irányítjuk, a windows minket irányít.

( uid_16313 | 2010. 05. 19., sze – 12:41 )

Nos, én jfs-t használok deadline I/O scheduler-rel linux alatt, igaz, csak desktop-on. Még soha nem volt semmi gondom vele. Több ram-ot zabál a kezelése mint pl. ext3-é, de a mai memóriaméreteknél ez nem probléma nálam, mert nem futtatok amúgy sem sok alkalmazást párhuzamosan.
Nekem bevált a jfs, mint használható alternatíva.

--
robyboy

"Gondolkozni nehéz, ezért legtöbben ítélnek." - Márai Sándor

( vtechun | 2013. 09. 05., cs – 18:42 )

Jelenleg mi az ajánlott, ha a hibatűrés a legfőbb szempont? Sebesség másodlagos, csak ne járjak így mint most ext4-el, hogy a superblockkal problémázott, aztán a végén töröltem a picsába. Reiser jó? , régebben vagy 8 éve nem volt vele gondom. Köszi

csak ne járjak így mint most ext4-el, hogy a superblockkal problémázott, aztán a végén töröltem a picsába.

Valamit elbasztál. Nálam évek óta nagyon jól érzik magukat a szerverek ext4 felett - minden diszken kikapcsolt write-back cache-sel, megfelelő mount opciókkal (noatime,nodiratime,journal_checksum,journal_async_commit,barrier=1,data=journal,commit=10).

Biztos lehetsz benne, hogy stabilabb. Hogy elég stabil-e, na az majd kiderül.
De a legfontosabb lépés az általam írtakban: a write-back cache kikapcsolása a diszkeken. Persze ezt a lépést ki lehet hagyni, ha nálad sosincs áramszünet, táphiba, meg hasonló azonnali diszkmegállások, de ha mégis bekövetkezik, akkor szinte biztos lesz az adatvesztés.

Igazából nem is az adatvesztés volt most a gond, hanem, hogy el se indult a gép normálisan. Pedig ez csak egy adat lemez, a rendszer nem ezen van. De nem tudta bemountolni, és emiatt ugye nem rendesen indult el a gép, hanem a give root passos formulánál kötött ki. Valamik le se futott az fsck...

Aha, az már nyilvánvaló, hogy badsectoros. Nem tolerálta szegény, hogy a macska rá-rá ugrott a htpcre :) addig nem is lett volna ezzel problémám, míg a gép elindulását nem akadályozza, mert adat nem volt rajta fontos. de valamiért az egyik áramszünet után már nem indult el, csak írta a "plase give root password for maintenance or press ctrl +d to continue"-t.
Ez volt csak a bajom igazából, hogy ezt nem tudta automatikusan megoldani... az ajánlott fsck se ment le.

En ext3-at es Reisert szoktam ajanlani, ebben a sorrendben. Probalgattam az Ext4-et, de szamomra nem hozta azt a "huha" erzest, hogy annyival jobb lenne az ext3-nal, mondjuk en 1T-nel kisebb particiokon hasznalom, talan ez a gond.

Reisert en is rettenetesen sokaig hasznaltam szerveren es desktopon egyarant, aztan szep fokozatosan szoktam le rola, elsosorban a desktop miatt, mert Windows alol ext2/3 particiot konnyebb olvasni, mint Reiser-t, aztan kesobb mar szerveren is ez lett automatikus. De igazabol sosem volt bajom a Reiserrel, szoval ha akarnam, tehetnek azt is a gepekre.

Vicces, de en egyetlen dolog miatt szeretem nagyon az ext2/3 fajlrendszert: a progressbaros fsck miatt. Az nagyon allat, es eddig egyik masik fsck se tudja, hiaba kapnak -C kapcsolot. Ami valahol szomoru.
-- 

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

SSD... az jo lenne, ha lenne... Amugy miert? Az ext4 miert jobb SSD-re mint az Ext3?

Torles: en 4G-nel nagyobb fajlt ritkan torlok, de ha igen, akkor egyszeruen hatterbe teszem az rm parancsot, aztan majd lefut. Nem uzemszeru nalam a torles-letrehozas-torles-letrehozas loop.
-- 

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

Így van. Én ext4-et használok SSD-vel, discard és noatime opciókkal.
Egyébként hiányzik egy valóban SSD-re optimalizált fájlrendszer, pedig de jó lenne, ha lenne! Ez op.rendszerre is igaz. Csomó mindent lehetne még optimalizálni (SSD-re).
--
robyboy

"Gondolkozni nehéz, ezért legtöbben ítélnek." - Márai Sándor

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

2007-ben kezdték a fejlesztést, 2008-ban már adtak ki általuk stabilnak tartott kódot. A kérdés szerintem itt már nem az, hogy a kód elég érett-e, hanem hogy mennyi felhasználója van. Ez utóbbit nem tudom. Ha sok, akkor egy fél évtizedes kódban már megbízok.

Szerk.: Utánaolvastam és visszavonom amit feljebb írtam, mert UBIFS nem a blokk eszköz fölé van tervezve, hanem firmware-nek - ahogy lejön nekem. Úgyhogy SSD-hez talán marad BtrFS Linux-on, amelybe be van építve a TRIM.

Ezek a választások:
https://wiki.archlinux.org/index.php/Solid_State_Drives#Choice_of_Files…

Nem gondolok neki elonyt. En alapvetoen hasznaltam mindkettot (3-ast es 4-est is) es nem ereztem semmilyen kulonbseget. Ugyanakkor a Total Commander Ext fajlrendszer olvasoja (DiskInternals Reader) csak 3-asig kezel azt hiszem, vagy legalabbis egy ideig nem tudta a 4-est rendesen olvasni. Mivel nekem idonkent szuksegem van a Linuxos particiorol fajlokra, igy szamomra fontos, hogy ez a resze zavartalanul mukodjon.

Viszont azt is tegyuk hozza, hogy en nem ertek annyira a fajlrendszerekhez, marmint az ilyen finom kulonbsegekhez. Ha csak az ext4-ben van trim support, akkor SSD-re nyilvan az az alkalmasabb - nekem viszont nincsenek SSD-s gepeim egyaltalan, legalabbis olyanok nincsenek, amik raw SSD-re dolgoznanak. Mindenfele RAID-es meg egyeb konfigjaim vannak, amiknel meg mar csak egy sokadik reteg a fajlrendszer. Ennelfogva _szamomra_ nem jelent kulonbseget az Ext4, mert ugy tudom, az egyetlen nagyobb ujitasa, hogy most mar hatekonyabban kezeli a nagy fajlokat.
-- 

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

"..Ugyanakkor a Total Commander Ext fajlrendszer olvasoja..."

"Viszont azt is tegyuk hozza, hogy en nem ertek annyira a fajlrendszerekhez, marmint az ilyen finom kulonbsegekhez."

"..nekem viszont nincsenek SSD-s gepeim egyaltalan..."

Ezek alapján a helyedben nem propagálnám az Ext3-at a 4-essel szemben.

A legtobb esetben hasonlo kornyezetbe kell ajanlani.

De egyebkent meggyozheto vagyok. Gyozz meg, hogy az ext4 jobb, mint az ext3. Mitol lesz nekem jobb?

Azt kulon nem ertem, hogy mi a baj azzal, hogy Total Commandert hasznalok Windows alatt?
-- 

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

Egy szemponttal szeretnék belekotnyeleskedni. Nekem is jó lenne az ext3. Szeretném, hogy minél stabilabb legyen a fájlrendszerem (nemröhög). Amiért az ext4-hez előre menekültem az amiatt van, hogy egyre többen ezt használják, mivel sok disztróhoz ez a default install. Így többen tesztelik is és több lesz a bug report. Eközben az ext3 egyre ritkább.
Az utóbbi időben egyre többször vagyok kénytelen hasonló megfontolásból előre menekülni. Az egész rendszer rolling. Még bírom szuflával. Egy ideig.

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."

"Az egész rendszer rolling. Még bírom szuflával. Egy ideig."

Ha sok időd rámegy, lődd be 1x jól aztán használd. Én sem frissítek destkopon állandóan, csak ha muszáj.
Pl. most is még Kubuntu 10.04 LTS megy, mi több kde3-mal. Én már csak ilyen maradi vagyok. Szerencsére tök jól megy minden.

Ha Linux alá ajánl valaki fájlrendszert másnak, akkor talán jobb ha nem a fenti ok miatt.

Habár meggyőzni nem akarlak, de:

http://en.wikipedia.org/wiki/Ext4#Features

Ha stabilnak tekintjük mindkettőt (márpedig annak tekinthetjük), akkor a sebesség különbség eleve nyomós érv.

" a Total Commander Ext fajlrendszer olvasoja (DiskInternals Reader) csak 3-asig kezel azt hiszem, vagy legalabbis egy ideig nem tudta a 4-est rendesen olvasni."

http://www.totalcmd.net/plugring/ext4.html

http://www.diskinternals.com/reader-for-tc/

nemtom hirtelen nekem melyik van fenn, de olvassa az ext4-et

A DiskInternals hivatalosan regota kezeli az ext4-et, eddig egyetlen egyszer probaltam ki, masfel eve talan? es hat... hogy is mondjam... szoval szeretkezett olvasni. Azota nem hiszek a cimkeknek.

A masik plugint nem is ismertem eddig, amit szoktam meg a DiskInternals-on kivul hasznalni az az Ext/Reiser plugin, mert az az Ext-et borzalmasan, viszont a Reiser-t korrektul kezeli. De manapsag mar riktan pakolom fel, mert nincs Reiser cuccom.
-- 

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

Khmm... minden formatum jo, amelyik mar bizonyitott. Az uj nem mindig jobb, lasd btrfs.

De egyebkent tenyleg szeretnek erveket hallani, hogy miert olyan jo az ext4. Latom azt, hogy mindenki torekszik az ext4 defaultta tetelere (marmint akik nem a btrfs-sel akarjak ugyanezt megtenni), csak az okat nem tudom. Gyozzetek meg, hogy jobb!
-- 

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

Te kezdtél el it általad mondott fogalom nélkül győzködni mást, hogy miért jobb az ext3. Azt írod hogy azért jobb mert te TC alól használod. Feljebb megkérdeztelek hogy ténylegesen miért jobb, de nem válaszoltál rá.

Az ext4 melletti érvre megadtam a wiki linket. Olvasd el. Szerintem inkább írd le te az érveidet.

Khm, en nem azt mondtam, hogy az ext3 generikusan jobb azert, mert TC-vel tudom hasznalni. Azt mondtam, hogy szamomra fontos szempont az, hogy TC-vel tudom hasznalni, mert ez nekem a workflow-m resze. SZAMOMRA ezert jobb. Szamodra lehet, hogy ez nem elony, de fenntartom a jogot arra, hogy nekem kulonbozo legyen dolgokrol a velemenyem, illetoleg a dolgokhoz valo hozzaallasom, mint neked. Es akkor mondjuk egyszerre: "Mi mind egyenisegek vagyunk"

A wiki leirja, hogy mi az ext4. De engem nem a szaraz leiras erdekel, hanem hogy a mindennapokban miert jobb hasznalni. Valaki hozott egy peldat, hogy a nagy fajlok torlese sokkal gyorsabb. Ez peldaul szamomra egy tok jo elonynek tunik, es most mar olyan helyre, ahol jellemzo az ilyen jellegu felhasznalas, merlegelni fogom az ext4 hasznalatat, mert van ertelme. Altalanossagban azonban meg mindig az a problemam vele, hogy nem ismerem, es mint ilyet, nem merem produktiv kornyezetben hasznalni. Mert szep es jo, hogy a dokumentacioban ezt meg azt leirjak, meg ilyen meg olyan, meg stabilnak tekintheto, de egyreszt nincs olyan ismerosom, aki ext4-et hasznalna barhol, masreszt nincs nagyon olyan rendszerem, ahol ezzel jatszani tudnek. Tudom, hogy ez megint az en szegenysegi bizonyitvanyom, mert miert nem tarolok otthon harom-negy gepet, es jatszok ilyesmikkel rajtuk, de igazabol annyira nem erdekel a dolog, hogy erre idot tudnek aldozni.

Arrol sincs peldaul info sehol, hogy erzekenyebb-e az aramszunetre (o, tudom: ilyen jobb helyeken nem fordul elo, mert szunetmentes), kernelpanikra, hasonlokra, mint az ext3.
-- 

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

"..en nem azt mondtam, hogy az ext3 generikusan jobb..."

"En ext3-at es Reisert szoktam ajanlani, ebben a sorrendben..."

Mégis te ajánlod, ezért megkérdezem hogy miért. Erre azt mondod hogy nem értesz hozzá. Utána meg hogy te igazából csak azt írod le, hogy neked miért jobb. Győzködsz embereket az igazadról, utána meg leírod hogy nem is.

A wiki-ben leírták hogy miért jobb. Gondolom nem olvastad el. A manualban a kapcsolókról megint el tudod olvasni, hogy hogy lehet úgy használni, hogy a lehető legkevésbé dőlhessen össze, pl. writeback nélkül.

Rakerdezek: van tapasztalatod is az ext4-gyel, vagy csak a wikit olvastad el? Engem nem a wiki erdekel, hanem a konkret tapasztalatok vele. Konkretan nem erddekel, hogy a fejlesztoi szerint ez a cucc ilyen meg olyan stabil. Az XFS is stabilnak van mondva, meg sztaroljak jobbra-balra, es megis olyan adatveszteseket produkal, hogy ihaj.
-- 

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

Több éve használom, most már egy jó ideje szervereken is. De hogy én mennyit és hogyan használom az nem lehet mérvadó stabilitás szempontjából. Inkább az, hogy nem igen találkozni net szerte konkrétan ext4-hez kapcsolódó probléma leírásokkal. Akkor még sok ilyen volt, amikor Ubuntu szállította először default-ként.

xfs_repair-t használtam már élesben és tette a dolgát. De tapasztalataim szerint az xfs az áramszüneteket és váratlan leállásokat kevésbé tolerálja, mint az ext3/4.

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."

+1

Nekem sok ev utan most volt az elso alkalom, hogy az xfs_repair nem akart semmit se kezdeni egy diszkkel. Szerencsere csak masolat volt, igy egy ujramasolas megoldotta a problemat, de jobban tudtam volna orulni, ha az xfs_repair teszi a dolgat.
-- 

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

Az az ő bajuk. Én 1 évig test drive-oltam az xfs-t egy kis szerveren (SunFire V240, 36GB-os SCSI diszkekkel). Aztán amikor egyszer feltűnt, hogy 5 perc alatt nem fut le egy kernelforrás könyvtárstruktúrájának a törlése, akkor berágtam, és leteszteltem egy tar xzf; rm -rf teszttel, hogy a standard fájlrendszerek mit tudnak. Az xfs volt a legszarabb - azóta használom az ext4-et.

Linux 3.9.9:
"Btrfs is highly experimental, and THE DISK FORMAT IS NOT YET FINALIZED. You should say N here unless you are interested in testing Btrfs with non-critical data."

Fura? Hogy mások nem szeretnek szopni?
Tudod van az a vicc, amikor a rádióban bemondják, hogy vigyázzanak az autópályán, mert egy őrült szembe megy a forgalommal...

Nálam nyilvánvalóan mást jelent a "supportált" fogalom, mint az Oracle-nél. Talán ezért nem dolgozom az Oracle support organizációban... ;-)

The "btrfsck" program is now available but, as of May 2012, it is described by the authors as "relatively new code" which has "not seen widespread testing on a large range of real-life breakage", and that "may cause additional damage in the process of repair".

Nézd, Te nyilvánvalóan soha nem próbáltad igénybe venni az Oracle fizetős supportját semmilyen Oracle termékhez, ez a töretlen bizalmadból egyértelmű. Én meg láttam ugyanezt belülről... mentségemre szolgáljon, hogy nem önszántamból lettem Larry beosztottja.

Csak a pelda kedveert nehanyat sorolok abbol, ami itt van korulottem es mar volt szerencsem support case-hez:

M9000
M10-4
T4-4
T2000
T5240
X4170
Sun Cluster
QFS
zonak, LDOM-ok

Nem azt irtam, hogy tokeletes, hanem azt, hogy van support :) Es a fenti esetekben maga a support igenis korrekt es gyors volt, ha valami benazas esett, akkor az a partnercegnel volt.

--
L

Egy dolog, h supportalt egy masik, hogy stabil-e.

tompos

ui.: Szemely szerint en sem mernem meg rabizni igazan teljes nyugodtan a dolgaimat, mivel meg nem kiforrott, de leginkabb azert, mert parszor mar megegettem magam vele;)
Ha jol tudom, a formatumat epp most keszulnek modositani a deduplikacio miatt. Pedig azt mar evekkel ezelott is stabilnak nyilvanitottak.

( uid_16313 | 2013. 09. 11., sze – 08:28 )

Van még egy érdekes hibrid megoldás is, ami az archwiki-ben szépen le van írva. EXT3 partició csatolása EXT4-ként:

Mounting ext3 partitions as ext4 without convertingRationaleA compromise between fully converting to ext4 and simply remaining with ext3 is to mount existing ext3 partitions as ext4.

Pros:

■Compatibility (the filesystem can continue to be mounted as ext3) – This allows users to still read the filesystem from other distributions/operating systems without ext4 support (e.g. Windows with ext3 drivers)
■Improved performance (though not as much as a fully-converted ext4 partition) – See Ext4 - Linux Kernel Newbies for details
Cons:

■Fewer features of ext4 are used (only those that do not change the disk format such as multiblock allocation and delayed allocation)
Note: Except for the relative novelty of ext4 (which can be seen as a risk), there is no major drawback to this technique.Procedure1.Edit /etc/fstab and change the 'type' from ext3 to ext4 for any partitions you would like to mount as ext4.
2.Re-mount the affected partitions.
3.Done.

--
robyboy

"Gondolkozni nehéz, ezért legtöbben ítélnek." - Márai Sándor

Elvben az ext particiok tudjak magukrol, hogy epp most milyen feature-k vannak bekapcsolva, nem? Tehat nem egy formatumazonosito kodot keresnek magukon (en most ext2 vagyok, en most ext3 vagyok, etc) hanem a bekapcsolt feature-k listaja alapjan mukodnek. Ugye ext2-bol is ugy lehetett ext3-at csinalni, hogy fogtad, es bekapcsoltad a journalt a particion. Es ugyanigy lehetett ext3-bol ext2-t is csinalni: kikapcsoltad a journalt.

Ez alapjan legfeljebb akkor lehet gond, ha a nem elerheto funkciokat akarnad kihasznalni valamivel - de azok eleg non-common use case-nak tunnek igy leiras alapjan.
-- 

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

Nem kötözködésként, de te sem voltál sokkal konkrétabb:

"lehet" ez a...
"azt gondolnám"...
"nem szeretnék"...

Egyébként én nem ajánlottam semmit, csak rámutattam egy létezö alternatívára.
Személy szerint fogalmam sincs, hogy a felvetett alapkérdésre mi a konkrét válasz. Egy biztos, én EXT4-et használok EXT4-ként felcsatolva, SSD-n, semmi bajom vele, de ez nem mérvadó, általánosítható.
Egy dolog biztos, amióta világ a világ, valahol az EXTx fájlrendszer volt mindig az un. "klasszikus" linux fájlrendszer, de ez sem jelent amúgy semmit.

--
robyboy

"Gondolkozni nehéz, ezért legtöbben ítélnek." - Márai Sándor