A fejlesztő által publikált néhány szám:
RAM: 8GB
Disk: 400GB disk.
CPU: Dual core hyperthreaded
[...]
Jelzések:
- 'vanilla': hagyományos ext3, változtatások nélkül
- 'mc': metaclustering technikával ellátott ext3
[...]
Benchmark 1: Sequential write to a 10GB file followed by 'sync'
1. vanilla:
Total: 3m9.0s
User: 0.08
System: 23s-48s (very high variance)
2. mc:
Total: 3m6.1s
User: 0.08s
System: 48.1s
Benchmark 2: Sequential read from a 10GB file.
Description: the file is created using same type of ext2 (mc or vanilla)
1. vanilla:
Total: 3m14.5s
User: 0.04s
System: 13.4s
2. mc:
Total: 3m14.5s
User: 0.04s
System: 13.3s
Benchmark 3: Random read from a 300GB file
Description: read using 512 byte chunk total 5MB
1. vanilla:
Total: 3m56.4s
User: ~0
System: 0.6s
2. mc:
Total: 3m51.4s
User: ~0
System: 0.8s
Benchmark 4: Random read from a 300GB file
Description: read using 512KB chunk total 1% size of the file
1. vanilla:
Total: 4m46.3s
User: ~0
System: 3.9s
2. mc:
Total: 4m44.4s
User: ~0
System: 3.9s
Benchmark 5: fsck
Description: Prepare a newly formated 400GB disk as follows: create
200 files of 0.5GB each, 100 files of 1GB each, 40 files of 2.5GB ech,
and 10 files of 10GB each. fsck command line: fsck -f -n
1. vanilla:
Total: 12m18.1s
User: 15.9s
System: 18.3s
2. mc:
Total: 4m47.0s
User: 16.0s
System: 17.1s
Benchmark 6: kernbench (this was done on an 8cpu machine with 32GB RAM)
1. vanilla:
Elapsed: 35.60
User: 228.79
System: 21.10
2. mc:
Elapsed: 35.12
User: 228.47
System: 21.08
Az LKML-re postázott patch formázásával kapcsolatban kritikák merültek fel, amelyek szerint a formázási problémák miatt a patch áttekintése, tesztelése nem könnyű feladat. Ezt a problémát a fejlesztő orvosolta a legfrissebb patch-ben. Emellett megjegyzésre került, hogy a patch nagy mennyiségű ext3 kódot bolygat, így indokolt a nagyon alapos tesztelés.
Bővebben a KernelTrap cikkében.
- A hozzászóláshoz be kell jelentkezni
- 2763 megtekintés
Hozzászólások
Nem lenne rossz felpörgetni az fsck-t. Én főleg emiatt részesítem előnyben a reiserfs-t.
- A hozzászóláshoz be kell jelentkezni
Nem egy szervert üzemeltetek én sem. FSCK nagy diszkeken, ahol van is adat rémálom, de az az igazság, hogy az ext2/ext3 is az, mivel ha valami hiba történik a fájlrendszerben (nem a naplózás által visszahozhatóra gondolok), akkor kevés esély van az adatok megmentésére.
Vannak sokkal jobb fájlrendszerek: XFS, JFS, reiserFS <- ezeket kell használni, lehetőleg LVM-ben és HW RAID-ben (3ware), így könnyen kiterjeszthetők, hibatűrők stb.
- A hozzászóláshoz be kell jelentkezni
És vannak olyan fájlrendszerek, amik nem kerülnek inkonzisztens állapotba.
$ zpool list
NAME SIZE USED AVAIL CAP HEALTH ALTROOT
data 3.62T 121G 3.51T 3% ONLINE -
- A hozzászóláshoz be kell jelentkezni
jaj, de a zfs az foloslegesen generalt igeny, mar megmondtak itt a szakertok
-. . - -... ... -..
- A hozzászóláshoz be kell jelentkezni
Szerintem nem ez (== fsck) a jövő, de átmenetileg megteszi.
It doesn't matter if you like my song as long as you can hear me sing
- A hozzászóláshoz be kell jelentkezni
jövök a szokásossal szvsz XFS, de a JFS is jó és ha a Btrfs elkészül, akkor az is beszáll a ringbe.
Az Ext4 fejlesztése ... meg nem is tudom milyen ... "stabil" kernelben fs-t fejleszteni ... nevetséges, Adrien Bunk multkor jelezte is ezt az lkml-en, de a reakciók negatívak voltak, pedig csak egy "depend on broken"-t akart adni az az fs-nek a kernelconfig-ban ...
linux v2.6.22.15 + madwifi v0.9.3.3-mal itt
debian gnu/linux @ linux-2.6.22.15-pancs1
- A hozzászóláshoz be kell jelentkezni
Miért ekkora etwas ez? Desktopokat használok, nem szervert, nálam néhanapján lefut oszt csókolom. Sok időt nem vesz el.
Szerveren ez problémás?
- A hozzászóláshoz be kell jelentkezni
Igen. De majd mások kifejtik, én nem értek hozzá. :) (Az egyetlen kérdés, hogy ahol sokáig tart fsck (nagy tárolókapacitás), ott miért pont ext3-at használnak?)
- A hozzászóláshoz be kell jelentkezni
Nem csak nagy tárólókapcitás miatt fut lassan az fsck. Van pár Fsünk ami 100GB több int 2 millió file. Na ebből van vagy négy 1db Linuxon meg pár apróság több mint 10 millió file összesen a gépen. Kb évente van újraindítva leállás időben és default (180 nap) az fsck időzítés. Mit mondjak nem két perc... (initben sorban fsck-z, parancssorból lehet párhuzamosan indítani fsck-t mindegyik fsre)
- A hozzászóláshoz be kell jelentkezni
Pl. egy negyed oras ext3 fsck egy produktiv szerveren amit egy barom rendszergazda veletlenul kinyomott, mert nem lat a szemetol, eleg bosszanto. Es konkret veszteseget okoz. Mind a ketto.
---
pontscho / fresh!mindworkz
- A hozzászóláshoz be kell jelentkezni
tune2fs? Mert fs integritás szempontjából pont az ilyen balesetek miatt használnak a legtöbben valami journalling-ot.
Ext3 fsck-t egy tervezett leállás során illene csinálni, a default beállítások a hülyeség ellen védenek. Mint tudjuk egy disk sem él örökké és badsector ellen a journal se véd, még kevésbé ha pont a journal területen van (mert mi mástól fogynának el a reallocation-ra fenntartott területek, ugye?)
- A hozzászóláshoz be kell jelentkezni
A journaling nem az adataid, hanem az fs-t vedi elso sorban. A tobbiben nagyjabol igazad van, de vak rendszergazda ellen az sem ved.
---
pontscho / fresh!mindworkz
- A hozzászóláshoz be kell jelentkezni
Az fsck meg visszahozza a (ki nem írt) adataid?
- A hozzászóláshoz be kell jelentkezni
?
---
pontscho / fresh!mindworkz
- A hozzászóláshoz be kell jelentkezni
sőt, még desktopon is idegesítő, ha negyed óráig bootol a 160 gigás ext3 vinyóról ;)
- A hozzászóláshoz be kell jelentkezni
Hogy már akksiról működő laptopról ne is beszéljünk.
- A hozzászóláshoz be kell jelentkezni
ez debianon nem ér, mert ha telepről megy, nem fsck-z, de ettől függetlenül idegesítő
- A hozzászóláshoz be kell jelentkezni
hm, a fenti írásból nem tudtam egyértelműen eldönteni, hogy a patch az fsck-t patcheli, vagy a kernel ext3 modulját, a KernelTrap cikkből látszik, hogy a kernelmodult. Szép estét!
- A hozzászóláshoz be kell jelentkezni
A cikkből:
"Emellett megjegyzésre került, hogy a patch nagy mennyiségű ext3 kódot bolygat, így indokolt a nagyon alapos tesztelés."
"Szép estét!"
Erősebb szemüveget! ;)
--
trey @ gépház
- A hozzászóláshoz be kell jelentkezni