Immaron majdnem egy hete hasznalok a Fedora Linux 17-et futtato laptopom kozos tarhelyen ZFS-t. Mukodik is, teljesen jol, minden faja, egy gondom van: borzalmasan lassu az olvasas rajta. Mintha nem lenne mogotte meg disk cache sem.
Jelenleg egy 2.10GHz -re hitelesitett i3-mal es 4G RAM-mal ellatott Lenovo G570-en fut egy Samsung winyon a cucc, es erzesre ket-haromszor lassabb olvasasom van rajta, akkor is, ha olyan fajlokat olvasok fel, amiket mar egyszer felolvastam. Konkretan: most par napig egy darab Rails projekten dolgoztam, relative keves fajlt modositva (a betoltott fajlok szamahoz kepest keveset), es a konzol meg ket egymas utani inditasnal is bunlassu volt, pedig tapasztalatbol tudom, hogy altalaban a masodik inditasra mar nem kell szinte egyaltalan varni ra.
Igazabol nem tudom, mit merjek, hogy teszteljem a dolgot. Azt tudom, hogy a disk, ami benne van, nem egy gyors darab - de hat elvben errol szolna a disk cache, hogy ezt megoldja, nem?
Mas: van olyan verzio a ZFS-bol ami tamogatja az inotify-t? Egy kazal minden epitene erre a kernelszolgaltatasra, de minden csak nyivakol, hogy ezt a fajlrendszert o nem ismeri, es nem is tudja rajta elerni az inotify szolgaltatast.
Hozzászólások
Mit jelent az, hogy "közös tárhelyen"? Hálózat, vagy multiboot esetén a közös partíció, vagy mi?
Legjobb tudomásom szerint a linuxos ZFS driver még messze nincs kész, az eredeti ZFS kódot megnyitotta a Sun/Oracle, de BSD licensz alatt, az meg nem jó a linuxnak - újra kell írni.
Konklúzió: Linuxon NE használj ZFS-t. Amúgy sem laptopra való, hanem szerverbe, a RAM igénye is jelentős. Ha hálózati ZFS cucc van, akkor meg NFS-en vagy Samba-n keresztül érd el.
FYI: zfsonlinux.org
FYI: az van fenn. Ha elFUSEraltam volna a gepet, azt kulon irtam volna, szamomra evidens a nativ megoldas hasznalata.
--
A válasz nem neked szólt, hanem a "licenc miatt újraírják a ZFS-t" kijelentést próbáltam új megvilágításba helyezni.
Kösz, erről lemaradtam. Az mondjuk elmond valamit a helyzetről, hogy az USA energia hivatala (DOE) rendelte meg...
Multiboot, OS X + Linux kozos particio, de eddig csak Linux mountolta.
Mar egyszer volt rola szo, halozatos megosztas nem megoldas, mert folyamatosan kell (akkor is, ha nem otthon vagyok), Ext driver csak nyugosen mountolhato irhatora OS X alatt (nem automata), a HFS meg Linux alatt instabil, mint allat. Egy sleepet nem bir ki tisztessegesen, regebben egyszeruen csak elcrashelt a gep a sleepbol feljovetel utani 2-5 oraban, mostanaban mar csak fsckzni kell idonkent, neha 1-2 logfajl eltunik, semmi komoly. Ironikus felmosoly.
Az NTFS-sel meg az a nyugom, hogy VirtualBox is futna ezekrol a particiokrol, es tapasztalatom szerint azt a linuxos NTFS-3G nem igazan birja, illetve birja, csak epp a gep a rajzolt lajhar sebessegere gyorsul fel, illetve le.
--
Sok suletlenseget hodasz ossze, ne hangoztasd.
tompos
Ez roppant hasznos hozzászólás a számomra, ebből már tudom is, hogy mi a sületlenség.
Amúgy te is jó tanácsot adtál a kollégának. Szóval úgy tűnik, sületlenség sületlenséget szül.
De suletlensegre reagalni is azt szul - szoval ha lehet ne folytassuk.
--
A teljesítménygondhoz nem tudok hozzászólni, inotifyt megnéztem:
Ubuntu 12.04, zfs verzió: 0.6.0.71-0ubuntu1~precise1
$ touch xxx
$ inotifywait -m xxx &
$ touch xxx
xxx OPEN
xxx ATTRIB
xxx CLOSE_WRITE,CLOSE
$
Nekem a tail nyavajog erte:
zfs-0.6.0-rc14.x86_64
--
Nekem ilyet nem csinal.
t
En javasoltam neked a zfs-t, de sajnos ilyen formaban nem tudok neked segiteni, mivel ilyen desktop kornyezetben sosem hasznaltam.
Mindenesetre pl. az atime-ot kapcsold ki, bar bizatosan nem ez a gondod.
Azt javaslom, hogy irja a zfs-discuss@zfsonlinux.org levlistara es ott segiteni fogjnak neked (tenyleg segitokeszek).
udv,
tamas
Hogy lehet erre feliratkozni? Ugy ertem, van valami webes felulet is, vagy csak echo subscribe | mail zfs-discuss@zfsonlinux ?
--
http://zfsonlinux.org/lists.html itt
--
>'The time has come,' the Walrus said<
Kosz
--
Leírhatnád mit mérsz raw disk sebességre,és mit mérsz ha ugyanezt zfsen ajánlod ki.
Io-performance
Milyen Os-en méred?:)(Zfsonlinux?)
zpool iostat 10 ?top?
RAW disket nem tudok merni - ertelemszeruen, mert nincs szabad particiom. Az jo, ha ext3-on merek?
Szerk: ok, olvastam a megszerkesztett postot is. Fedora 17, ZFS on Linux.
Szerk 2: ide folyamatosan fogom feltolteni az infokat.
zfs iostat (a 10 ?top? parametereket nem tudta ertelmezni):
--
#top (összevetve io művelettel.)
#zpool iostat -v 10 (10 masodpercenkent vesz mintat)
Megnézem neked virtuális gépen mit mérek.
Update1:Freebsdn mérve.
Update2:Fedore 17 telepítés alatt.
Nekem az altalad adott adat tul gyorsan lefutott, igy kicsit nagyobb fajllal tesztelek...
Ezek kurva jo adatoknak tunnek, de nem tudom, hogy a zfs nem erzekeli-e a /dev/zero -val valo tesztet. A valodi sebesseg ennel sokkal kevesebbnek erzodik
Csak egy momentum: az elobb epp egy Ubuntu Precise virtualis gepet probaltam uptodate allapotra hozni, es az updatek kb. egy ora alatt akartak lejonni egy alapvetoen 50MBites kapcsolaton, parszaz meganyi update. Irrealis.
A bonnie++ telepites alatt.
--
Volt vmi nagyon hasonlo thread nemreg a listan, tenyleg javaslom, h nezd meg.
Milyen opciokkal hoztad letre az fs-t? Hogyan particionaltad a HDD-t?
Mit mond a strace, mit csinal, amikor sokat molyol?
tompos
Nem tudom rendesen stracelni, mert kismillio fajlt olvas fel, a felet nem is errol a partiorol.
Opciokkal? Oszinten szolva nem hasznaltam semmi extrat. zpool create stuffz, zfs create stuffz/projects talan. Talan megadtam a mount pointot is, de ennyi, nem is tudom, hogy a zfs-nek egyaltalan milyen opciokat lehet atadni.
A HDD particionalasa ugy nez ki, hogy ez a particio egy logikai cucc, sda8 vagy sda9 most fejbol meg nem mondom neked. Semmi extrat nem vittem bele.
Itt egy bonnie kimenet a ZFS-rol, bar nem birtam kivarni, es az ext3 cuccrol elinditottam egy filmet. Ha kell, ejjel meg merek egyet film nelkul.
A listaban talaltam egy txg_sync -es szalat, de nalam az a processz meg sem jelenik.
Furcsa amugy. Most ugyanaz az Ubuntu Precise upgrade nagysagrendekkel gyorsabbna lefut. Mintha valamitol fuggne, hogy lassu, de igazabol semmi nem fut a hatterben, ami a zfs-t bokdosne, vagy akar a disket.
Nem tudom, mi lehet a nyug, sajnos en ehhez a reszehez mar hulye vagyok. Ezert is kertem segitseget.
Szerk mittudomenmennyi: csinaltam zpool iostat merest az ubuntu upgrade kozben, gondolom, az eleg eroteljes.
--
A zfs szereti maga kezelni az egesz diszket, mert akkor o kezeli a cache-t, meg miegymast. Ha megis particiot kap, akkor erdemes figyelni a sectorharokra, errol nemreg volt itt a forumban egy eleg jo osszefoglalo. Ill. nezd meg az ashift=9 es az ashift=12 kozottu kulonbseget.
udv,
t
Ha felhomalyositanad szegeny ostoba elmemet, hogy mi az az ashift, annak merhetetlenul halas tudnek lenni... :-)
--
A szektorméret ZFS-kernelváltozója. (AF, aka 4K diskeknél érdekes, oda 12 kell az alapértelmezett 9 (512) helyett. Egyes implementációk (nem) tudják ezt kezelni.)
/etc/lib/lu/plugins/lupi_bebasicTehat a /etc/modprobe.d ala kell ezeket beirni?
Illetve melyiket ajanlod? Tenyleg hulye vagyok ezekhez...
Valamint: meg lehet nezni, hogy most mennyi? A /sys/ alatt tobb valtozo is elerheto, ami FreeBSD-n is, igy ha azt mondod, lehet, hogy eleg nekem.
--
Nem, ezt a zpool létrehozásakor adhatod (?*) csak meg; utóbb nem változtatható meg. Ellenőrizni a jelenlegit a 'zdb' kimenetéből tudod.
*Solarison nem támogatott, de van hozzá olyan bináris (zpool), amit jótét lelkek megpatkoltak és az hardcoded ashift=12-t tartalmaz. A derivatívok némelyike állítólag már tud ilyet paraméterként.
/etc/lib/lu/plugins/lupi_bebasicNekem is 12. Az jo?
--
Mennyi a merevlemezed logikai és fizikai szektormérete? (Egyébként való igaz, ahogy fentebb is mondták, szerencsésebb a ZFS-nek teljes lemezeszközöket odaadni.)
/etc/lib/lu/plugins/lupi_bebasicNem ZFS-nél ugyan, de tudtommal nem okoz gondot, ha egy 512byte-os szektorral rendelkező lemezt 4k aligmenttel partícionálunk, ugyan olyan, mintha 512byte-ra lenne igazítva. Gondolom itt is meg lehet csinálni, hogy mindig fixen ashift=12 van. Főleg ha néhány rendszeren fixen 12 az értéke.
Tekintve, hogy a Windows keptelen a ZFS kezelesere, ez viccesen nezne ki, ezen felul az OS X sem kepes gyokerrendszerkent elkezelni a ZFS-t.
A szektormeretre: az fdisk 512 / 4096 logical / physical aranyt ir ki, nem tudom, ebben mennyire lehet megbizni?
--
Nezz utana google-n:0
Azert javaslom ezt, mert ugysem tudnam leirni helyesen/jol. De szerencsere mas igen es meg is tette.
udv,
t
Az a bajom, hogy amikor ilyen zfs infokat keresek, szinte mindig zraidos tortenetekbe szaladok bele, az meg tok mas - amennyire en tudom - mint az en felallasom.
--
Mi az a zraid?
t
A ZFS tud RAID-ot, a helyesirasaban nem vagyok biztos, zRAID vagy ZRAID vagy RAIDz...
--
ja, raidz(x)
A zfs egyben sw raid es volume manager is.
De ha rakeresel erre a google-n, te is meg fogod talalni, nemcsak raidz jon elo.
http://zfsonlinux.org/faq.html#PerformanceConsideration
udv,
t
100-116 IOPS nagyon sok egy diszknél.
Ez kb. ennyit tud.
Annyit még megemlítenék, hogy a zfs alapból 128k blokkmérettel dolgozik (legalábbis Solaris-on, de valószínűleg linuxon is ez a default), ami nagy mennyiségű adat, kicsi fájlok és random io esetén jelentősen rontja az olvasási teljesítményt.
Érdemes megmérni valamivel az átlagos IO méretet, és ahoz igazítani a ZFS blokkméretét.
Még valami: dd-vel teljesen felesleges bármit mérni, hacsak nem kimondottan nagy IO méretű szekvenciális IO teljesítményére vagyunk kiváncsiak. Irodai file szerver, desktop, adatbázis szerver esetén tipikusan kis blokkméret random IO-ja van.
dd: Tudom, csak megis valami szamot ad
Igen, ez igy soknak tunik, es exten is valami hasonlot mertem. De nem is a mert ertekekkel van a baj, hanem azzal, hogy mintha nem letezne a disk cache vagy a fajlrendszer cache fogalma. Nem tudom elhinni, hogy egy ./script/console ket _egymasutani_ meghivasa pontosan ugyanolyan bunlassu legyen, es legalabb ketszer, de inkabb haromszor lassabb mint a szar, ganyolt, reverse-engineered HFS-en. Ezt nem tudom elfogadni.
--