btrfs 0.11 teszt Ubuntu Hardy-n

Chris Mason a 0.10-es verzió után nem sokkal a napokban kiadta a következő generációs Linux filerendszer, a btrfs (HupWiki szócikk) újabb fejlesztői snapshot-ját. A filerendszer jelenleg erősen fejlesztés alatt áll. Olyannyira, hogy a végleges diszkformátuma is éppen csak kialakulóban van. Ez azt jelenti, hogy a korábban létrehozott btrfs filerendszerek nem biztos, hogy kompatibilisek az újabb btrfs-progs segédprogramokkal, ezért a formátumváltásokkor a btrfs filerendszert le kell menteni, újra kell formázni az újabb verziójú mkfs.btrfs programmal, majd vissza kell állítani backup-ból a filerendszer tartalmát) -, szóval éles használatra még koránt sincs kész. A btrfs fejlesztése Chris folyamatosan frissített ütemterve szerint körülbelül egy év múlva jut el oda, hogy a tervezett szolgáltatások (pl. online fsck) többsége implementálásra kerül.
A filerendszerek fejlesztésének ily korai szakaszában alig van érdeklődő, csak azok ássák bele mélyebben magukat az ilyen projektekbe, akik vagy fejlesztők, vagy a tesztelésben próbálnak segítkezni. A btrfs az előzetesen publikált szolgáltatáslistája alapján felkeltette az érdeklődésemet, ezért úgy döntöttem, hogy belefogok a tesztelésébe és a hibabejelentések beküldésébe. Teszterből soha sincs elég és a btrfs users levlistáját elnézve a projekt nem is dúskál az alpha teszterekben.
A projekt életét már hónapok óta figyelemmel kísérem, mert valószínűleg ez lesz az a filerendszer, amely a desktop gépemen egyszer majd leváltja az öregedő és aktív fejlesztéssel már nem rendelkező ReiserFS-t. Sőt, az sem kizárt, hogy a szervereken az általam használt ext3-at is, így a segédkezés egy kicsit önös érdekből is történik.
Ez az írás arról szól, hogy hogyan lehet a btrfs filerendszert alapszinten beüzemelni Ubuntu 8.04 "Hardy Heron" alpha3 alatt. Emellett néhány szó esik a tesztelés eredményéről is. A terv az, hogy rendszeres időközönként beszámolok a btrfs fejlesztését nyomonkövető tesztelés tapasztalatairól.

Előkészületek

A tesztelés megkezdéséhez a hardy-alternate-i386 ISO-ról felrántott parancssori rendszert használtam. A boot menüből kiválasztott alaprendszer telepítése tökéletesen megfelel a célnak. A Hardy Heron alaprendszer telepítése során hagytam a merevlemezen annyi partícionálatlan területet, amelyen tesztelni tudom a btrfs-t. A rendszer tesztelését virtuális gépen végzem, hogy igény esetén könnyen lehessen további merevlemezeket adni a rendszerhez. A btrfs használatához le kell majd fordítanunk a filerendszer kernelmodulját (btrfs-0.11) és a segédprogramjait (btrfs-progs-0.11), így szükségünk lesz azokra a "szerszámokra", amelyet például egy kernelfordításkor használunk (binutils, make, gcc, stb.). Ezeket telepítsük fel.

A btrfs beszerzése

A btrfs használatához szükségünk van a btrfs 0.11-es verziójú kernelmoduljának és segédprogramjainak forrására. Ezeket letölthetjük az Oracle open source portáljáról.

A fordítás

A btrfs a kernel "libcrc32c" modulját használja a file- és metaadatok cheksum-olásra, így erre szükségünk lesz. Szerencsére az Ubuntu kernel ezt alapértelmezetten szállítja, így nem kell kernel(modult)t fordítanunk.

A btrfs kernelmodul fordításához szükség van a rendszer alatt futó kernel header filejaira. A megfelelő csomagot telepítsük fel. Esetünkben:

apt-get install linux-headers-2.6.24-4-generic

Ezután lefordíthatjuk a kernelmodult. Ezt egy egyszerű "make" parancs kiadásával megtehetjük a btrfs-0.11.tar.bz2 archívból kibontott könyvtárban. Sajnos a 0.11-es verzió jelenleg nem fordul le hiba nélkül az Ubuntu Hardy alapértelmezett kernelével (vanilla kernelre fejlesztik):


root@btrfstest:/tmp/btrfs-0.11# make
make -C /lib/modules/`uname -r`/build M=`pwd` modules
make[1]: Entering directory `/usr/src/linux-headers-2.6.24-4-generic'
  CC [M]  /tmp/btrfs-0.11/super.o
  CC [M]  /tmp/btrfs-0.11/ctree.o
  CC [M]  /tmp/btrfs-0.11/extent-tree.o
  CC [M]  /tmp/btrfs-0.11/print-tree.o
  CC [M]  /tmp/btrfs-0.11/root-tree.o
  CC [M]  /tmp/btrfs-0.11/dir-item.o
  CC [M]  /tmp/btrfs-0.11/hash.o
  CC [M]  /tmp/btrfs-0.11/file-item.o
  CC [M]  /tmp/btrfs-0.11/inode-item.o
  CC [M]  /tmp/btrfs-0.11/inode-map.o
  CC [M]  /tmp/btrfs-0.11/disk-io.o
  CC [M]  /tmp/btrfs-0.11/transaction.o
  CC [M]  /tmp/btrfs-0.11/bit-radix.o
  CC [M]  /tmp/btrfs-0.11/inode.o
  CC [M]  /tmp/btrfs-0.11/file.o
/tmp/btrfs-0.11/file.c: In function ‘btrfs_file_write’:
/tmp/btrfs-0.11/file.c:722: warning: passing argument 1 of ‘remove_suid’ from incompatible 
pointer type
  CC [M]  /tmp/btrfs-0.11/tree-defrag.o
  CC [M]  /tmp/btrfs-0.11/extent_map.o
  CC [M]  /tmp/btrfs-0.11/sysfs.o
  CC [M]  /tmp/btrfs-0.11/struct-funcs.o
  CC [M]  /tmp/btrfs-0.11/xattr.o
  CC [M]  /tmp/btrfs-0.11/ordered-data.o
  CC [M]  /tmp/btrfs-0.11/acl.o
  LD [M]  /tmp/btrfs-0.11/btrfs.o
  Building modules, stage 2.
  MODPOST 1 modules
  CC      /tmp/btrfs-0.11/btrfs.mod.o
  LD [M]  /tmp/btrfs-0.11/btrfs.ko
make[1]: Leaving directory `/usr/src/linux-headers-2.6.24-4-generic'

A kernelmodul ugyan elkészül, be is tölthető, de a filerendszerre másoláskor "Segmentation fault" az eredmény.


root@btrfstest:/tmp# dd if=/dev/zero of=foobar bs=1024 count=100000
100000+0 records in
100000+0 records out
102400000 bytes (102 MB) copied, 15.5326 seconds, 6.6 MB/s
root@btrfstest:/tmp# cp foobar /mnt/
Segmentation fault

A problémát bejelentettem a brfs-users levlistára. Nem sokkal ezután jelentkeztek a fejlesztők és Jeff Mahoney, a SUSE Labs egyik alkalmazottja küldött egy patch-et. A patch alkalmazása után már probléma nélkül lefordítható kernelmodul.

A kernelmodul a lefordítás után betölthető és a segfault sem jelentkezik.


mkdir /lib/modules/`uname -r`/kernel/fs/btrfs
cp btrfs.ko /lib/modules/`uname -r`/kernel/fs/btrfs
depmod -a
modprobe libcrc32c
modprobe btrfs

Ezzel a btrfs kernelmodult be is töltöttük. Letesztelhetjük egy lsmod-dal:


root@btrfstest:/lib/modules/2.6.24-4-generic/kernel/fs/btrfs# lsmod | grep btrfs
btrfs                 221684  1 
libcrc32c               3584  1 btrfs

A két modult betehetjük a /etc/modules file-ba, így boot-oláskor automatikusan betöltődnek.

A kernelmodul után le kell fordítanunk a btrfs segédprogramjait. A btrfs-progs-0.11 lefordításához fel kell telepítenünk az "uuid-dev" csomagot:

apt-get install uuid-dev

Ezután lepörgethetjük a btrfs-progrs-t:


root@btrfstest:/tmp/btrfs-progs-0.11# make
[...]
gcc -Wp,-MMD,./.debug-tree.o.d,-MT,debug-tree.o -Wall -fno-strict-aliasing -D_FILE_OFFSET_BITS=64
-g -Werror -c debug-tree.c
gcc -g -Werror -o debug-tree ctree.o disk-io.o radix-tree.o extent-tree.o print-tree.o root-tree.o
dir-item.o 
hash.o file-item.o inode-item.o inode-map.o crc32c.o rbtree.o extent-cache.o extent_map.o
debug-tree.o -luuid 

Ha kész, akkor egy "make install"-lal telepíthetjük a /usr/local/bin alá őket:


root@btrfstest:/tmp/btrfs-progs-0.11# ls -la /usr/local/bin/
total 988
drwxr-xr-x  2 root root   4096 2008-01-19 16:52 .
drwxr-xr-x 10 root root   4096 2008-01-19 14:47 ..
-rwxr-xr-x  1 root root 333668 2008-01-19 16:52 btrfsck
-rwxr-xr-x  1 root root  13336 2008-01-19 16:52 btrfsctl
-rwxr-xr-x  1 root root 305828 2008-01-19 16:52 debug-tree
-rwxr-xr-x  1 root root 327723 2008-01-19 16:52 mkfs.btrfs

Ha elkészültünk, akkor itt az idő a btrfs filerendszer elkészítésére:


root@btrfstest:/tmp/btrfs-progs-0.11# mkfs.btrfs /dev/sda5
fs created on /dev/sda5 nodesize 16384 leafsize 16384 sectorsize 4096 bytes 1998708736

Miután elkészült a filerendszer formázása, azt mount-olhatjuk:


root@btrfstest:/tmp/btrfs-progs-0.11# mount -t btrfs /dev/sda5 /home/trey

Ellenőrzés:


root@btrfstest:/tmp/btrfs-progs-0.11# mount
[...]
/dev/sda5 on /home/trey type btrfs (rw,none)

Ha automatikusan akarjuk csatolni, akkor vegyük fel a btrfs filerendszert az /etc/fstab fileba.

Tapasztalatok

A filerendszert Samba-n keresztül kiajánlottam a host operációs rendszer számára.


root@alderaan:/# mount
[...]
//192.168.10.10/trey on /mnt type smbfs (rw)

Az alapvető filerendszer-kezeléssel kapcsolatos dolgok (másolás, törlés, könyvtárkészítés, alapvető jogok állítása) már működnek.
Nálam jelenleg a filerendszer nyúzása (kernelfordítás több szálon, közben mp3 hallgatás Samba-n keresztül, stb.) folyik. Annak ellenére, hogy az FS látszólag problémamentesen használható a mindennapi feladatokra, SEMMIKÉPPEN SEM AJÁNLOTT rajta fontos adatokat tárolni!

A tesztelés folytatódik, remélhetőleg hamarosan már a filerendszer fejlettebb képességeiről is be tudok majd számolni!

Hozzászólások

A negatív véleményeidet (desktop usernek minek, de szerverre sem, mert még tele van buggal) olvasva a ZFS-ről nem értem ezt a lelkesedést a btrfs-sel kapcsolatban. :)

Miben lesz ez jobb desktopon, mint a reiserfs, vagy bármely másik Linuxban elérhető? Mit tud ez, amit a Linuxban jelenleg elérhető megoldások nem? (mintha lett volna ilyen is, de lehet, hogy nem pont tőled :)

A Reiser4-re vártam, de abból nem lesz semmi. Ez egy deklaráltan általános célú FS lesz, fejlesztési iránya _desktop_ és szerver (maga fejlesztő mondta el egy interjúban). Reiser-hez hasonló btree-szerű filerendszer (nem véletlen, hiszen Chris Mason volt, aki a journaling képességeket implementálta a ReiserFS-be). Már most nyomokban gyorsabb, mint a jelenlegi filerendszerek. A ReiserFS-nél én fsck-val nem nagyon találkoztam több év használat alatt sem, így az nagyon nem játszik, de ha mégis kell, akkor lesz online fsck. De válaszolva a kérdésedre, a ReiserFS fejlesztése megállt (aktívan ki tudja meddig lesz karbantartva), Reiser4 nem nagyon lesz, így azon gondolkozom, hogy keresni kellene valamit helyette. Ez jónak látszik. Mögötte az Oracle-lel pláne. Főleg, hogy így talán az adatbázisokkal sem lesz problémája.

--
trey @ gépház

tényleg trey, az XFS-t pár próbáltad használni?
azt a jellegzetes "kinullázást" megszüntették a 2.6.22-es kernelektől kezdve, ami akkor jelentkezhetett, ha a gép alól ki lett tolva az áram ... véleményem szerint az XFS is egy jó fs, és e mögött is egy elég nagy cég áll, az SGI. A clusetereiken is ezt az fs-t használják. Nagy fileoknál és párhuzamos írás-olvasás esetén is gyors, csak sok kis file esetén _sokkal_ lassabb, mint a ReiserFS.
Az XFS pedig b+ tree használ.

szerintem érdemes ránézned.

szerk.:
http://cs.nyu.edu/rgrimm/teaching/sp07-os/xfs.pdf
http://www.ibm.com/developerworks/library/l-fs9.html
http://oss.sgi.com/projects/xfs
http://oss.sgi.com/projects/xfs/training/index.html

linux v2.6.22.15 + madwifi v0.9.3.3-mal itt
debian gnu/linux @ linux-2.6.22.16-pancs1

Próbáltam én már mindent az évek alatt. JFS, XFS, ext3 (itt a HUP archívumban vannak róla cikkek). Nekem desktop-on a ReiserFS jött be, szerveren az ext3-at telepítem. Kíváncsi vagyok arra, hogy mi lesz még az ext4-ből. A btrfs most egy 256 MB RAM-mal rendelkező vmware-ben fut, ami 800 MHz-es host-on megy. Megy rajta egy kernelfordítás, Samban keresztül döcögén nélkül hallgatok MP3-at. Elsőre nem rossz. Kiderül mi lesz belőle. Mason sebességtesztjei is meggyőzőek.

--
trey @ gépház

azért az EXT4 fejlesztési modellje is érdekes ... egy stabil fába fejleszteni egy nem stabil kódot, ennyi erővel a btrfs-t is be lehetne rakni. Adrien Bunk múltkor épp azért harcolt (sikertelenül), hogy az EXT4 kapjon egy broken flag-et a kconfig-ban, mivel még nem stabil az fs és pár helyen már élesben használják, de még itt sem fix a ondisc image

linux v2.6.22.15 + madwifi v0.9.3.3-mal itt
debian gnu/linux @ linux-2.6.22.16-pancs1

Ok, de miert baj az? ha a kernel mas reszet nem erinti, akkor beletehetik, ugyse nagyon fogja hasznalni senki sem, marmint hacsak nem olyan aki direkt azt akarja tesztelni. Aki sajat maga fordit kernelt, annak sajat felelosege hogy tudja mit mire szabad es mire nem. Aki meg a disztribicio kernelet hasznalja gondolom ott nem talalkozik vele, vagy van olyan elterjedt disztrib ami ajanlja/lehetove teszi mar az ext4 fs hasznalatat akar telepitesnel is?

éredeks módon nekem annó ment annó, van valami; igaz én az mbr-be szoktam rakni és nem az adott particióra stage1_5_xfs vagy mi grubnál és azzal megy, csak annyira nem kiforrott állítólag
de lilo az simán megy, a /boot-on is XFS-t használok és gond nélkül mennek.

"Az SGI nem csődölt még be"
de, de azóta ismét él

linux v2.6.22.15 + madwifi v0.9.3.3-mal itt
debian gnu/linux @ linux-2.6.22.16-pancs1

Miért nem ZFS? Ennek több oka is van.

- Linuxon NINCS ZFS
- A ZFS-nek a visszajelzések szerint horror HW igényei vannak
- nekem a Sunban már régen elveszett a bizalmam, ami lassan jön vissza (Schwartz óta javulófélben van nálam :)
- ha licenc fetisiszta lennék, akkor azt mondanám, hogy ez GPL
- voltak bíztató visszajelzések már tavaly augusztusban

(First let me congratulate you for the nice job on btrfs. I've been stress testing it with parallel kernel compiles intermixed with snapshot taking, up to about ~100 load avg on a dual core box and it's doing quite well :-))

- és végül: csak

--
trey @ gépház

Ok. Még egy tipp: a btrfs otthonosabb érzés. Lehet tesztelni, bugreportolni, a ZFS-t meg az ember nyakába zúdítja egy multi. Viszont mindkét esetben technológiai kísérletről van szó, és korábbról úgy tűnt, feleslegesnek tartod az ilyen kísérleteket. Erre utalt bra kérdése.
--
CCC3

Nem tudom, ami ZFS tartományvezérlőt én üzemeltetek, abba kell a 4G RAM, meg az amd64, de ezek ma már szerintem az alapok egy szerverhez, "főleg a mai filléres memóriaárak mellett". Otthoni fileserverre nem ez a legjobb, de arra meg más kell.
It doesn't matter if you like my song as long as you can hear me sing

mondjuk ez is igaz, de ha így vesszük, akkor az XFS is egy "idegen", mivel alapból irix-re lett fejlesztve, de az sgi átportolta annó linux alá és mivel az irix fejlesztését befejezték pár éve, ezért most 100%-ban a linuxra fejlesztenek, szóval már ez is tekinthető egy nativ linuxos fsnek

szerk.:
és ha megnézed a kódját, igényesen meg van írva

linux v2.6.22.15 + madwifi v0.9.3.3-mal itt
debian gnu/linux @ linux-2.6.22.16-pancs1

Én nem nézegetem a kódját. Csak használom. Teljesen alap nálam, hogy xfs-t használok minden partíción, kivéve a /boot-ot. (Leszámítva azt az eset, amikor PXE-n kapja meg a kernelét egy szerver)
Szóval, én úgy vagyok vele, ahogy Lenin elvtárs is megmondta: XFS, XFS, XFS.

Az azonban tény, hogy a btrfs egy hangyányit az én fantáziám is megmozgatta. Eddig egyedül az xfs-nél láttam online átméretezést, és az is csak növelni tud. A btrfs-re meg csökkentést is írnak. Ráadásul azt is online.
Kíváncsi lennék egy tervezett btrfs feature lista vs. xfs jelenlegi feature lista összehasonlításra.

Tulajdonképpen miért jó az XFS? A lent hivatkozott tesztben förtelmes eredményeket produkált.
Én mondjuk csak egy rm párterabájtos\ fájl-ra emlékszem homályosan a múltból, ami nem is tartott tovább pár percnél.

És hadd vegyem elő trey érvelését: az XFS-t teljesen más környezetbe tervezték, a Linuxba csak cipőkanállal sikerült beleerőszakolni. :)

nem a nagy fájlokkal van gondja, hanem a sok kicsivel, ami Ext2/3 és Reiser alatt 2 perc az XFS alatt 12 .. egyszer teszteltem, csináltam pár 100 000 vagy millió kis szar file és nem tudtam mikor lesz vége, de ezt leszámítva jó, ext2/3-t és Reisert már nyúztam szét áramszünettel XFS-t még nem. Nagy fileok esetén gyorsabb és paralell írás és olvasás esetén is gyorsabb.

linux v2.6.22.15 + madwifi v0.9.3.3-mal itt
debian gnu/linux @ linux-2.6.22.16-pancs1

Nem én teszteltem, hanem az adatbázisos kollega. bonnie-val, bonnie++-al, meg "érzésre", hogy rátett postgres-t, és úgy mennyire hasít. Arra számított, hogy az ext2+noatime mountopció lesz az überalles, aztán neki is leesett az álla, amikor még erre is rávert az xfs.

Egy dologban lassú csak: fájlok törlése. Minden másban nekem abszolút gyors. A cipőkanalas sztoriról én nem tudok. Out of the box működik debianban, ubuntuban. Hogy milyen nehézségek árán portolták a linuxra hidegen hagy. Ami érdekel, hogy működik-e, és hogy hogyan.

Nem ertem. Ez az online atmeretezes akkora nagy cucc?

Regebben azert tettem reiserfs-t par helyre, mert az tudott online atmeretezni (azt hiszem, csak novelnem kellett, de mintha csokkenteni is tudna). Akkoriban ext3-ra valami uzenet jott, hogy online csak ezzel-azzal megy.

De mar evek ota nem jon uzenet, szoval ext3-at hasznalok, LVM-en megy online noveles tuti, es ugy emlekszem, szamos esetben csokkentettem is a meretet. Valoszinuleg online, de erre most nem teszem le a nagy eskut.

G

Te is felsz majd, mikor a seggfej felszakerto megrendelo igenye szerint ezt kell telepitened, lerohad a backupgep linkje es szetrohad a filerendszered, es szopsz jo 90 orat a semmiert, csak azert, hogy ne mondjak azt, nem csinalsz vele semmit, mert eleve nem tamogattad azt, hogy ezt hasznaljak. Ez a baj vele technologiai hablaty, egy felig kesz es experimental allapotban levo fs, ami neha mondom _neha_ jobb eredmenyt szolgaltat. Kell a halalnak.

az lehet, de nem mindegy, hogy az FS-nek milyen környezetet adunk (*BSD, Darwin, SunOS ...)

a freebsd-ben is elérhető az xfs, de azzal inkább még nem próbálkozok, mivel kezdetlegesen támogatott, ugyan így lennék a linuxos zfs-sel

linux v2.6.22.15 + madwifi v0.9.3.3-mal itt
debian gnu/linux @ linux-2.6.22.16-pancs1

UNIXokhoz elegge hasonlo VFS layerek vannak implementalva, mar csak a POSIXos fs kezeles miatt is (tudtommal - nem irtam meg fs kodot), igy annyira borzasztoan nem hinnem h elterne az FS altal adott API. Raadasul mar az SGI is inuxban utazik.

Szal sztm a portolt cucc minosege ettol nem fugghet oly nagyon, bar lehetseges h figyelembe vettek linux kernel altal nyujtott spec. szolgaltatasokat is a brtfs tervezesnel. Tud vki ilyenrol amugy?

Minden területnek jót tesz néha egy teljes újraimplementálás. Egyszerűen a fejlesztőkben kikristályosodnak a dolgok :-).
Ez valamennyire a ReiserFS utódjának tekinthető "intellektuális" szempontból :-).
Ha a problémára adott választ újraírja valaki aki eddig is a problémán dolgozott akkor az szinte garantáltan jobb lesz, mint az előző, feltéve hogy befejezi.

Hmm, ez engem is erdekel. Szoval hajra! :)

Bocsi , ez nekem sok egyelőre de egy alapvető laikus kérdés mint külső szemlélő :)

A végeleges verziót érdemes lesz majd sebbesség/tudás szinten összemérni mondjuk a ext3-al?

Tudás szinten jóval többet fog tudni. Sebességet előre nehéz megjósolni. Most az alpha stádiumban kb. ugyanott van, ahol a jelenlegi FS-ek, néhol rájuk is ver, van olyan terület, ahol lemarad. Ez a fejlesztés során akár rosszabb is lehet, de akár javulhat is. Ezt előre nem lehet megjósolni.

--
trey @ gépház

Erdemes elolvasni a feature list-et: http://oss.oracle.com/projects/btrfs/
Eleg csak ezekre ralesni:

* Strong integration with device mapper for multiple device support
* Online filesystem check
* Subvolumes (separate internal filesystem roots)

Ez (Object level mirroring and striping) ha azt jelenti amit gondolok(pl egy directory-t mirroroz - FIXME) akkor az eleg finom.

Persze a puding probaja az eves lesz, de jo lenne mar linuxra is ilyen ZFS szeru szolgaltatasokat nyujto FS (multidevice, beepitett raid 1+0).

Ext3-hoz nem is nagyon lesz hasonlithato tudasban (brtfs javara termeszetesen).

Mar nem azert, de enyhen fizetos, a snapshot lehetosege pedig szanalmas volt, mikor 2 eve kerdeztem sunos tanfolyamon. (copy on write az nem volt ismert eljaras szamara, hanem lemasolta az egesz FS particiot:P)
Tovabba: nincs storage pool-ja (neked kell eszkabalnod a groupokat). Tehat en azt mondanam, h inkabb egy jobban supportalt LVM+FS-nek felel meg. Tudtommal pl. meretet sem lehet csokkenteni az fsnek, s nincsen volume in volume.
En ennyit tudok rola, cafoljatok meg.

"Drives are getting bigger, but not much faster"
vs
http://www.theregister.co.uk/2008/01/14/emc_adds_ssds_symmetrix/

Úgy tűnik, hogy a jövő az lesz, hogy a mostani -a merevlemezek fizikájához igazított- fájlrendszerek kikopnak (szóvicc :), vagy legalábbis átalakulnak, mivel teljesen más szempontok válnak fontossá.

igen, ebben lehet valami ...
most megint csak az XFS-sel tudok jönni, ahol a lemezt AG-kre van bontva, AllocationGroups és ha jól emlékszem, egy ilyen AG mérete 0,5 és 4 GB között lehet (FIXME) és ezáltal gyorsabb az üres helyek megtalálása. A másik ilyen, hogy minden AG-ben két b+ tree van, amelyek közül az egyik a szabad helyeket tartalmazza méret szerint, a másik meg fizikai hely szerint. Szóval XFS az nem egy alavult FS.

linux v2.6.22.15 + madwifi v0.9.3.3-mal itt
debian gnu/linux @ linux-2.6.22.16-pancs1

Na ez egy jo kerdes milyen file system tulajdonsagok kellenek, hogy az SSD-t hatekonyan hasznald.

A wikipedia azt mondja az eee pc ext3-at hasznal.

"The Eee PC uses an ext2/ext3 file system. It uses UnionFS to make the root file system. Recovery partition, in the form of a static image, is also resident on the SSD. This allows users to update everything on the file system and still reset the operating system to factory defaults later. Storage on the image, however, cannot be recovered: if a software package is uninstalled, no space is freed, and if a package is updated it may take up space twice. On 4 GB models, 1.4 GB is available to the user; on 8 GB models, 5.1 GB is available."

Ami meg erdekes, hogy az Apple kihozza a MacBook Air-t 64GB SSD-vel, vajon HFS+ fel van erre keszitve?

vannak direkt flash hw-kra kifejlestette fs-ek:
LogFS, JFFS, JFFS2 ... de valami módszert kitaláltak, amivel a sima fs-el is rendesen használhatóak és biztosítja, hogy egyenletesen legyen terhelve a hw

linux v2.6.22.15 + madwifi v0.9.3.3-mal itt
debian gnu/linux @ linux-2.6.22.16-pancs1

A modern SSD-kben hasznalt flash-ek mennyi irasi ciklust birnak?
Mert ha 1 millioval szamolunk, akkor ha 1 mp alatt 10x irunk egy helyre, akkor kicsit tobb mint egy nap alatt kinyirjuk.
Nyilvan ez extrem korulmenynek szamit, de azert elgondolkodtato, hogy szukseg van-e vmifele automatikus superblock athelyezest tamogato FS-re (gondolom a superblockok irodnak leggyakrabban)...

+1 write endurance, valahogy ezt nem szeretik kiirni a gyartok

Amire en gondoltam eloszor az a logical - phyisical block mapping, mivel a hdd-k forognak ezert az egymas melletti blockok nem egymas mellett vannak a disken, az ssd-nel nincs forgas, ugy irod mint a memoriat. Ez a resz teljesen transzparens lenne a file rendszer tervezesenel? ha az, akkor minek erolkodnek minden filerendszer es adatbazis konyvben a blockok fizikai elredezesevel, ha nem akkor miert nincs benne a file rendszer roadmap-ekben?

+1

egyebkent is ki a fene torol minden nap millio fajlt?
a masik meg ext3 mal probalt mar vki tobb terrabajtos vinyot formazni? homokora orakig ...

Ja hát ugye ha default beállítással csinálod, akkor több milliárd inode-ot fog gyártani rá, azért olyan lassú. Nagy filerendszereknél általában én át szoktam paraméterezni, hogy 1-2 milliónál ne legyen több, sőt ha kifejezetten nagy fileok tárolására lesz, akkor százezer is bőven elég. Egy pillanat alatt megvan az mkfs és az fsck is lényegesen gyorsabb lesz utána.
---
Sok gyerekkel ellentétben én sose akartam tűzoltó lenni. Lettem helyette informatikus. Nem találjátok ki, hogy mit csinálok nap mint nap...

Hmmm... Felkeltette az érdeklődésemet ez az FS. Figyelemmel kísérem a jövőben.

-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-

Ubuntu 6.06, Windows XP Pro

hm. két szimpi fs van most, ami talán egyszer leválthatja a mostani ext3-at: btrfs és zfs. viszont ha jól értem, btrfs nem lesz bsd-re (a következő 2-3 évben biztos nem), zfs meg linuxra, max valami fuse okosság. ehh