Az Intel nyílt forrású technológiákkal foglalkozó központjánál (Open Source Technology Centre) dolgozó David Woodhouse a napokban bejelentette, hogy megkezdte a RAID5 és RAID6 támogatás implementálását a Btrfs-be. A részletek itt és itt.
- A hozzászóláshoz be kell jelentkezni
- 2855 megtekintés
Hozzászólások
trey, szoktad még tesztelni mostanában a btrfs-t? Mi a személyes benyomásod, hogy halad a fejlesztés?
- A hozzászóláshoz be kell jelentkezni
Amióta a mainline kernel része lett, nem nagyon volt időm foglalkozni vele. Azóta nincs standalone git fa, így nem olyan egyszerű a tesztelése mint amikor volt. A levlistát folyamatosan követem. Hogy milyen állapotban van jelenleg stabilitás szempontból azt nem tudom. Az biztos, hogy az "erősen fejlesztés alatt áll" megállja a helyét :)
--
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Sysbench-csel egyszerűen el lehet rohasztani a kernelt, ha btrfs-sel tesztelsz.
Összehasonlító adatok hamarosan a blogomban.
suckIT szopás minden nap! ZFS funkciók
- A hozzászóláshoz be kell jelentkezni
Biztos volt már, de miért jobb, ha az ilyen több fizikai eszközös támogatást fájlrendszer szinten valósítanak meg?
- A hozzászóláshoz be kell jelentkezni
mert nemkell kulon volume manager? meg meg x. reteg?
- A hozzászóláshoz be kell jelentkezni
+1, meg lehet, hog a filerendszer így intelligensebben tudja a blokkokat allokálni, esetleg a journal-t is intelligensebben tudja kezelni, lévén, hogy tud róla, hogy RAID rendszeren van.
- A hozzászóláshoz be kell jelentkezni
az miert jo ha nincs kulon volume manager meg meg x. reteg? gyorsabb (monolitikus kernel)? attekinthetobb? vagy mi?
- Use the Source Luke ! -
- A hozzászóláshoz be kell jelentkezni
"az miert jo ha nincs kulon volume manager meg meg x. reteg?"
Mert az egyes rétegek közötti adatmozgatás teljesítményvesztéssel jár.
"(monolitikus kernel)"
Ezt nem értem, hogy jön ide
Ha jól emlékszem lesz rá lehetőség, hogy a fájlrendszer egyes könyvtáraira megadható lesz hogy RAID-ben legyenek, ha ezt a megszokott külön partíció, ... módszerrel kellene megoldani, főleg egy már éles fájlrendszeren, elég körülményes tud lenni.
- A hozzászóláshoz be kell jelentkezni
"(monolitikus kernel)"
Ezt nem értem, hogy jön ide
ugy, hogy a monolitikus kernelben a modulok minden overhead nelkul tudjak egymast hivogatni es adatot atadni.
tehat ha a filesystem driver meghivja a beleepitett raid_write fuggvenyt, az nem gyorsabb mintha ehelyett
az lvm_write-ot hivna "a masik retegben", szerintem nincs lenyegi kulonbseg, hogy masik reteget hivnak vagy
beepitett fuggvenyt.
- Use the Source Luke ! -
- A hozzászóláshoz be kell jelentkezni
viszont a pure_write mindig gyorsabb lesz.
--
()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.
- A hozzászóláshoz be kell jelentkezni
És ez tényleg így működik a monolitikus kernelben (melyikben, hol, minél?), vagy csak saccolod? Nincs ott semmi queue, meg ilyesmi, csak meghívja egy pointerrel a raid_write-ot, aztán már diszken is van minden...
suckIT szopás minden nap! A nagy öreg a fiatal csirke ellen - UFS vs. ZFS
- A hozzászóláshoz be kell jelentkezni
feltetelezem a zfs megfelelo beepitett fuggvenyet meghivva is ugyanugy van queue (mert mondjuk meg nem sikerult kiirni a diszkre az elozo adatot, vagy addig tobb zfs filesystem muveletet - amik mondjuk mas diszkeket erintenek - nem szabad vegezni?).
amugy tudod a mikrokernelben a retegek (pl. driverek) kozti hivasnak nagy az overheadje, mert van olyankor egy par context switch, stb - egy monolitikus kernel (pl. linux) ilyen teljesitmeny problemakkal nem kuzd, mert egy cimterben 0-as privilegiumi szinten fut az egesz (x86), erre gondoltam.
- Use the Source Luke ! -
- A hozzászóláshoz be kell jelentkezni
> Mert az egyes rétegek közötti adatmozgatás teljesítményvesztéssel jár.
egy lvm esetében milyen adatot kell mozgatni, amely mozgatás teljesítményvesztéssel jár?
- A hozzászóláshoz be kell jelentkezni
mdadm + lvm esetén kell egy align a disken az fd partíciónak, egy az lvm -nek, egy pedig az lvm -re tett filerendszernek az optimális sebesség elérésének érdekében. Akinek ezt elsőre sikerül összehozni, annak csak gratulálni tudok. :) Ezek nagyrészt megúszhatók, ha egy réteg kezeli az egészet.
- A hozzászóláshoz be kell jelentkezni
Elvileg semmit ,gyakorlatilag merhato a kulonbseg :(
Amit nem lehet megirni assemblyben, azt nem lehet megirni.
- A hozzászóláshoz be kell jelentkezni
\off:
mi ez az uj divat hogy a szokoz utan van a vesszo?
- A hozzászóláshoz be kell jelentkezni
- A hozzászóláshoz be kell jelentkezni
nem ugyanaz
- A hozzászóláshoz be kell jelentkezni
"az miert jo ha nincs kulon volume manager meg meg x. reteg?"
Mert az egyes rétegek közötti adatmozgatás teljesítményvesztéssel jár.
Ez csak minimális teljesítményvesztéssel jár.
A hangsúly azon van -amit te is írtál a második felében-, hogy így akár fájl szinten állítható a raid elrendezés. Pl egy gyakran olvasott fájl lehet raid1 -ben N diszkre elosztva, miközben a többi raid5 -ben. Ezt igen macerás lenne úgy megoldani, hogy a RAID egy külön (block) layer.
- A hozzászóláshoz be kell jelentkezni
Ez jól hangzik, de ez elméleti fejtegetés, vagy ilyen létezik/tervbe van véve valahol?
"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee."
-- Ted Ts'o
- A hozzászóláshoz be kell jelentkezni
Valami előadás anyagában hallottam ilyet vagy a ZFS vagy a Btrfs kapcsán, de forrást nem tudok, szóval egyelőre tényleg elméleti.
- A hozzászóláshoz be kell jelentkezni
Meg tudod mondani a "VIF" :) állományokra, hogy ezt bizony tegye rá az összes lemezre. A kevésbé fontos állományokat pedig elég egy lemezre tenni, ha az eldobja magát, akkor maximum elveszett a HTTP proxy cache.
--
http://wiki.javaforum.hu/confluence-2.10/display/FREEBSD
- A hozzászóláshoz be kell jelentkezni
mar dap is leirta, de a flexibilitas azert nem rossz feature.
amugy meg minel kevesebb plusz reteg, minel inkabb egy kezben van az egesz, hogy igy mondjam, annal inkabb stabilabb.
gondolj bele, egy linuxon mondjuk kell raidelned (md driver), kell ra mondjuk lvm, aminek kell a dm, aztan ott az lvm kodja. ez mar rogton 3 kulonallo resz (az mas kerdes, hogy a dm -et es az lvmet ugyanazok a sracok fejlesztik, AFAIK)
- A hozzászóláshoz be kell jelentkezni
Az LVM magában is tud RAID-et, csak szeretik elfelejteni sokan.
--
Wir sind erfasst, sind infiziert
Jedes Gespräch wird kontrolliert.
- A hozzászóláshoz be kell jelentkezni
Na látod, most már a fájlrendszer is fog tudni önmagában RAID-et.
- A hozzászóláshoz be kell jelentkezni
ZFS?:D
mondjuk az igaz h a reszleges mirror (pl ezt a konyvtarat mirrorozd, a tobbire meg jo a raid5 vagy a raid0) ott sincs megoldva.
De pl amugy nagy elonye a ZFSnek (s remelem a brtfs-ben is lesz ilyen), hogy nem kell particionalni, hanem csak mondod h kerek egy volume-ot, es ha nem korlatozom be a maximalis meretet akkor az rahizhat az egesz pool-ra....
- A hozzászóláshoz be kell jelentkezni
És ezzel meg is oldja a könyvtár mirror-t.
A ZFS-nek nincs versenytársa, és ha az Oracle-nek van egy kis esze, nem is lesz. Mire a btrfs eljut a kicsit is stabil állapotba, addig a ZFS-hez már megjelenhetnek az első cluster-kiegészítések (natív cluster fájlrendszer a zpool és zfs kezelhetőségének egyszerűségével)...
- A hozzászóláshoz be kell jelentkezni
Pedig a verseny jot tesz mindket felnek. Arrol nem beszelve, hogy amig a ZFS nem lesz linuxon is nativan elerheto (ugy ertem, nativan), addig nem ellenfelek.
--
()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.
- A hozzászóláshoz be kell jelentkezni
Amíg nem elérhető natívan Linuxon, addigis OpenSolaris-t használok, szóval tényleg nem ellenfelek :) 2009.06 óta igazán csak annyi kifogásom van vele, hogy kicsit több hely kell neki, mint egy átlag-linuxnak.
A btrfs számomra majd akkor lesz ellenfél, ha tud ilyent: mirror + checksum, encryption, mindez amazon ec2-n.
- A hozzászóláshoz be kell jelentkezni
Nekem a publikus információkból (amiket találtam persze) nem úgy tűnik, hogy nagyon a shared fs részen dolgoznának, inkább próbálják magukat utolérni az UFS feature-ökkel...
suckIT szopás minden nap! A nagy öreg a fiatal csirke ellen - UFS vs. ZFS
- A hozzászóláshoz be kell jelentkezni
Par eve talan. Es csak LVM2 (persze ez meg a legkisebb gond). Azonban mikor meg az egy-ket evvel ezelotti kernelben is experimental volt a mirror-os device mapper (LVM2 ezt hasznalja mirrorra) (mast nem lehetett alatenni az MD-nek sem az igaz), akkor azert elgondolkodtam, h hogy is van ez.
Az egyetlen sw mirror megoldas az aktualis kernelben experimental? hmmm....
- A hozzászóláshoz be kell jelentkezni