mondjuk annyi elonye van, hogy a sima listazas is gyors marad
Ez igaz, viszont az megmaradt volna akkor is, ha a hasht nem szuszakolja be a bejegyzések közé, hanem egy külön data streambe rakja. A kompatibilitást sem befolyásolta volna, és a hash tábla beolvasás hatékonysága sem lenne a béka segge alatt.
ez nem mondhato el pl. a btree-s reiserfs vagy btrfs-rol
Ezzel nagyon nagyon egyet értek. Szerintem is azért hülyeség a B+tree használata fájlrendszerekben, mert lehet, hogy egy elem keresése gyors vele, viszont minden más művelet (hozzáadás, törlés, listázás) meg nehézkes, körülményes és/vagy lassú. Ha csak a forrás olvashatóságát és minőségét nézem (a Linux kernelmodulokét), akkor ezt a B+tree-t legszebben a BeFS oldja meg, de még arra is érvényes mindez (pedig ott még beraktak egy overflow pointert is a node-okba, hogy a listázást gyorsítsák, mégis a hozzáadás és a törlés továbbra is lassú és körülményes).
Szerény véleményem szerint a Linux kernelmodulok közül az XFS B+tree implementációja a legcsúnyább, túltolták benne az absztrakciós szinteket, irdatlan mennyiségű függvényt használ feleslegesen. Ezek aztán alkalmasint beiktatnak egy indirekt függvényhívást, így szerencsétlen fordítónak esélye sincs, hogy fordításkor kioptimalizálja inline-ba ezeket, emiatt pedig megmarad a szükségtelenül hosszú függvényhívási lánc futási időben is. Függvénypointerek helyett szerencsésebb lett volna egy switch arra a pár esetre, ami előfordulhat (két-három lehetőségről beszélünk csak), akkor legalább a fordító ki tudná optimalizálni ezt a zagyva kódot. Arról nem is beszélve, hogy minden második függvény saját cache-t tart fenn, csak azt nem tudom, minek, mikor a Linux kernel önmagában megoldja a blokkok cache-elését. Nem baj, legalább rengeteg kernel memóriát elpazarol vele, és használhatatlanná válik tőle a kernel LRU...