Ext4 vs Btrfs

Előzmény. Cseréltem asztali rendszerem alatt az Ext4 fájlrendszert Btrfs-re az SSD-men.

Futtattam bonnie++ tesztet. Ext4 eredmény, Btrfs eredmény. Fedora 17 x64, stock kernel 3.5.3, minden szoftver és hardver ugyanaz volt a tesztek alatt.

Megj.: Btrfs compress és ssd opciókkal van felcsatolva, tehát használok tömörítést. Illetve mindkét fájl rendszerre relatíve újonnan toltam fel az adataimat rsync-kel. Egy nem mérvadó érdekesség, hogy 8%-ot nyomott össze az összes adatomon.

Röviden (Ext4 mennyivel gyorsabb):
Sequential output block 1.17x
Sequential output rewrite 0.91x
Sequential input block 1.08x
Random seeks 6.42x
Sequential create 1.15x
Random create 1.36x

Hideg indítás után egy updatedb parancs Ext4 alatt <5 sec alatt szokott futni, most Btrfs alatt meg ~7 sec.

Rendszer használat alatt nem veszek észre semmilyen sebesség különbséget egyelőre. Később még megírom majd folyamatosan a tapasztalatokat.

( log69 | 2012. 09. 09., v – 22:24 )

Közben megfordult a fejemben, hogy mivel a gyökért / mentem az egyik saját alkönyvtárába, vajon a snapshot gyökerében is ott van-e a snapshot könyvtár, és akkor abban? :) Mint tükör a tükörben effekt.. Na de nem, a snapshot mappák léteznek, de üresek :)

Azért kíváncsi lennék, hogy már a fejlesztés elején gondoltak-e erre?

Ha valaki nem ért annyira hozzá és kell neki, beteszem ide a script-emet, amelyet cron-ból futtatok óránként readonly snapshot létrehozásához, érdemes inkább a /root mappába tenni mint a user-ébe: 


mkdir /snapshot

crontab -l
# create readonly btrfs snapshot of root dir
11 * * * * /root/snapshot.sh

cat /root/snapshot.sh
#!/bin/sh
# create snapshot and delete oldest ones

# number of snapshots to leave
# 168 for a week (+1 for tail)
N="169"
DIR="/snapshot"

# create it
btrfs sub snap -r / /snapshot/`date +%Y%m%d%H%M%S`

# delete oldest ones
ls "$DIR" | tac | tail -n+"$N" | \
    while read FF; do btrfs sub del "/snapshot/$FF"; done

Szerintem inkabb az van a dolog hattereben, hogy a mentendo inode-okat meg mappakat meg jo elore felscanneli, mielott a snapshot fajlt letrehozna. Igy akkor meg nem is letezik az a file/inode.

A tac-ot viszont feleslegesen lovod fel. Az ls-nek van forditva listazo parametere (-r). Es meg ket tipp: /bin/ls, valamint -1.

-- 

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

A /bin/ls -t en nem emiatt szeretem, hanem azert, mert nehany bugos shell kepes az aliasolt ls-t felhasznalni, ahol egy csomo kapcsolo bejon meg az altalam megadottak ele, ami nem biztos, hogy az, amit en szeretnek. A teljes utvonallal megadott ls-nel viszont ilyen problema fel sem merul.
-- 

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

Közben rájöttem hogy az óránkénti snapshot túl sok és felesleges. Sima cron helyett áttettem az anacron cron.daily-jébe a job-ot, és csak 7 példányt hagyok, így 1 hétre megvan az elérhető napi 1 snapshot.

Az óránkéntinél azért gyorsan elfogyhatna a hely, mert ez akár 168 db snapshot-nál jócskán összeadódhat ha mindig változna valami nagyobb óránként, az meg azért sokat megenne.

Azt ugy szoktak, h 24 oraig orankent tart meg, 1 hetre naponta, 1 honapra hetente, felevre pedig minden honap elso meglevo peldanyat.
Vagy vmi hasonlo.

Persze ugy redukalod, ahogy jol esik.

tompos

ui.: Kozben rajottem, amit a masik(?) thread-ben irtam, snapper a neve es vmi suse-s tool. Ubuntu repoban nem latom, Fedorat nem tudom.
Amugy ez hogy van? Fel eve meg azt bizonygattad, h neked pont eleg a redhat es fo a stabilitas, nem kell neked a sok uj feature...stb.

Igen pont a snapper-t néztem, Fedorában nincs benne, gondolom a SLED-be extraként nyomatták bele. Az SP2 demózáskor is azt mutogatták a videón.

A stabilitásról: fordult most egyet nálam a kerék. SL-be jött egy kernel frissítés, amely több mint 1 hónapra eltörte a rendszeremet a wifi-vel kapcsolatban illetve folyamatos kernel panic-ok voltak, amelyel 5 éve nem találkoztam a notimon - majd az újrabb frissítések sem oldották meg, és ez a regresszió visszajelzés alapján is jelent volt minden RHEL és klónjaiban, aztán tele lett e t.., ekkor felrepült a Fedora :)

Egyébként közel default használok mindent, mert tudom hogy ez van legjobban kitesztelve ahhoz képest, és nem sűrűn találkoztam még hibával. Igaz kb. 3 hónapra a kiadás után tettem fel. Meg a hibás kernel mellett volt még egy nagy húzóerőm: a Gnome 3-at ki akartam próbálni napi használat mellett, amelyet kényelmesnek találok. Illetve egy fejlesztésemet is ki akartam tesztelni legújabb Ruby és MySQL alatt.

Arra számítók, hogy maradok a Fedora vonalon, mert azért izgalmasak az új feature-ök, aztán valszeg egy idő után visszaállok majd egy hosszan támogatott stabil vonalra (majd SL7 környékén).

A Btrfs-nél meg mivel ahogy írtam, február óta szállítja Ora és Suse, meg egyébként is nagyon sűrűn mentek, a snapshot és tömörítés miatt beadtam a derekam. :)

( log69 | 2012. 09. 10., h – 10:20 )

Még egy megjegyzés, más nehogy belefusson:

Először szívattam magamat külön boot partíció létrehozásával, és annak grub2-be beállításával, miután láttam hogy nem kell, mert a legfrissebb grub2 a Fedorában már simán tud boot-olni Btrfs-ről is. Így elég 1 db partíció.

Viszont nem lehet vele használni swap fájlt, mert lyukakat használ az FS-en (gondolom hasonlóan, mint amit Ext3/4 is tud, és ls -s opcióval lehet megnézni), és emiatt hibát dob a swapfile felcstolásakor. Én mindig fájlt használtam külön partíció helyett, de ha valakinek kell swap, akkor Btrfs mellé külön partíciót kell neki csinálni egyelőre.

Igen, de mivel mindig van annyi RAM-om, hogy alig nyúl a rendszer a swap-hoz, ráadásul SSD-n, ezért nem szeretek partíciót tologatni. Főleg ha pl. több memóriát veszek, akkor fájllal könnyen nagyobbra állítom a méretét, hogy a hibernáláshoz beleférjen.

Egyébként meg venni kell RAM-ot. :)

Swap file Btrfs-en való használathoz kiegészítés:

3.6-os kerneltől migráltak egy patchset-et, amely lehetővé teszi:

https://btrfs.wiki.kernel.org/index.php/FAQ#Does_btrfs_support_swap_fil…

"There is a patchset (swap-over-nfs) which enhances the swapfile API and btrfs could build swap support on top of the infrastructure. The patchset has been merged into 3.6."