Az fsck felgyorsítása "Metaclustering" technikával

Címkék

Abhishek Rai egy patch-csel állt elő, amely saját jellemzése szerint "jelentősen felgyorsítja az fsck-t ext3 filerendszeren egy technikával, amelyet Metaclustering-nek hívnak". Egy korábbi szálban a fejlesztő elmondta, hogy "ez a patch segít csökkenteni a teljes fsck időt ext3-on. 50-65%-os csökkenést tapasztaltam az fsck idő tekintetében amikor a patch-et használtam egy majdnem teli filerendszeren. Néhány fsck optimalizációval ez 80% lehet."

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.

Hozzászólások

Nem lenne rossz felpörgetni az fsck-t. Én főleg emiatt részesítem előnyben a reiserfs-t.

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.

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

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

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?

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)

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?)

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!