én még mindig ott tartok, hogy ha van egy cache-centrikus enterprise storage-od, akkor még mindig a legjobban úgy jársz, ha az adatbázis lognak csinálsz külön zpool-t, ami _alig nagyobb_, mint a logjaid. (még jobb lenne ugye a zilt is kikapcsolni, de ugye global setting és a datadirekhez meg kell, meg hát ellenjavallt.) párszor már "rengeteget" javult a dolog és nem kétséges, hogy egy kisebb méretű storage-on gyakorlatilag jobban jársz, ha rátolod az egészet egy nagy zpool-ra, mint ha nekiállsz "hagyományos" fájlrendszerekre szabdalni a dolgot. de egy nagyobb storage-nál marhára nem mindegy, hogy a cache benyeli a logot és nem keletkezik háttértranzakció, vagy a ZFS teleszemeteli az egész zpool-t akkor is, ha ugyanazokat a 4 gigás fájlokat írod (COW...) és a storage cache átalakul egy bufferré a gép és a lemezek között, nem mellékesen teleszemetelve azt is. végül is nem akkora gáz a külön zpool, de messze nem "as advertised", meg be kell delegálni a datasetet (pathname érdekességek), clusternél betenni a hasp-be, ha már hasp akkor RG switchnél 2 zpool-ért imádkozni, hogy simán menjen, mert ha nem, akkor az egész géped döglik, jó esetben csak a zfs, df -h, stb parancsok fognak befagyni és üzemelhetsz tovább, rossz esetben panic, ha volt egy jó nagy zpool-od mountolva a gépen, akkor lehet reménykedni, hogy a cluster resource-okban elég legyen a timeout, mert egy 2 terás dataset recovery-je bizony 20 perc (szerintem az átlagosnál gyorsabb diszkekről), nem mintha más fájlrendszerrel gyorsabb lenne, de ebben az esetben nem jó, hogy nem kiszámítható, és hogy a zfs, df -h csomó minden behal, amíg tart (mintha olvastam volna most valamit zpool-onként külön processzről), és hogy a cluster doksikban/scriptekben szó nincs ezekről az esetekről, pedig léteznek. workaround: clrg offline, tartalék gépre átprezentálni a LUN-t, ott megvárni, amíg befejeződik a zpool import (tart, ameddig tart), zpool export, utána a clusteren mehet a clrg online :)