Új hozzászólás Aktív témák

• #3455 janos666 nagyúr F34R #3454

  Új Válasz 2016-09-26 22:00:32 #3455

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  janos666

  nagyúr

  válasz F34R #3454 üzenetére

  Szerintem semmi köze a disztróhoz, a mainline kernelben, illetve zfs git repóban van a lényeg, amibe a gentoo-source patchset csak minimálisan nyúl bele (sőt, alapvetően csak extra opciókat ad a menuconfig-ba, nem kényszereket teremt, vagy módosít) és ez is csak javasolt, de nem kötelező (használható a vanilla-source is). A ZFS kód azt hiszem közel 1:1 GIT-ről jött gentoo patch-ek nélkül (kivéve az extra useflag-eket), ahogy a Btrfs userland-hez sincs tudtommal érdemi patch a gentoo ebuild-ban.

  Ez szerintem kifejezetten jó is a gentoo-nál, hogy egyszerűen át tudom tekinteni, mi az, ami esetleg disztró-specifikus és mi nem, de általában jó tipp, hogy alapjáraton semmi sem az (mármint, ami "kintről jön", nem kimondottan a gentoo-hoz készül), és ha mégis, akkor sem megkerülhetetlen / kibogozhatatlan.
  Más disztróknál is utána lehet járni ennek, de általában az a kerülőút, hogy fogasd újra magadnak a disztróspecifikus patch-ek nélkül, ilyenkor pedig kényelmes, ha eleve forráskód alapú a disztró és a csomagkezelő.

  Amit a disztró tehet az esetleg az, hogy automatikusan átállítja az IO és/vagy CPU ütemezők paramétereit, esetleg beidőzít cron-al egy defrag-ot, netán btrfs balance-ot, stb.

  Vagy, ha messzebbre gondolkozunk, a Solaris megfordult a fejemben, de tudtommal oda, a zárt verzióhoz sem készült el soha ZFS-hez a Block Pointer Rewrite (és aki dolgozott rajta azt mondja örül is neki, hogy nem fejezte be és reméli más sem fogja helyette, mert "az lenne az utolsó feature", túlkomplikálná a jövőbeni változtatásokat), ami lehetővé tenné az online defrag-ot és a profilok közti online váltást (amiket a Btrfs már tud). Szóval ilyen szempontból ez most irreleváns. Linux-on relatívan zabálta a CPU-t a ZFS, de nem bántam, mert nem hiányzott másra (és talán jobban feküdt volna egy kicsi, de friss Intel CPU-nak, mint az öreg AMD csodának, amitől amúgy is épp szabadulni tervezek).

  A töredezettség pedig talán más mértékben alakul ki és/vagy érződik a megléte, de igazából nem a filerendszer, hanem a HDD "hibája". FAT32-t is használhatnék, azon is töredezetté válhatnak előbb-utóbb a file-ok, ha folyamatosan cserélődik egy részük, ez pedig mindig meglátszik az elvileg szekvenciális műveleteken, ha igazából mégsem azok, mert csattognak a HDD fejek a töredékekért. Ezért lehet hasznos a defrag (ez van EXT4-hez és Btrfs-hez is, ZFS-hez viszont nincs).

  Láttam a bcachefs-t. Az első benyomásom szerint semmi értelme, és többet ért volna valami olyasmit összerakni, mint a ZFS féle L2ARC. Csak nem is kell ARC, lehet sima "utolsó olvasat" cache, csak legyen olyan módja, ahol csak metadata megy rá, és ideális esetben kérésre automatikusan próbálja meg teletömni a metadata block-ok tartalmával hidegindítás után (reboot után melegen indulni biztos bonyolult, de ez nem tűnik annak).

  A legnagyobb balszerencsém a Btrfs-el csak az volt, hogy nekem pont a RAID-5 profil tűnik ideálisnak, míg a fejlesztők általában olyan szélsőségesen állnak a kérdéshez, hogy kétféle adat van, az egyiket minimum RAID1 (vagy 1+0) profillal tárolod és van róla off-site, off-line backup, 2+ példányban (a tenger alatti titkos bunkerben ólomszéfben, és a nagyi pincéjében is a dunsztosüveg mögött, a patkányfogó alatt alufóliában), vagy "szarsz rá" és olyan, mint ha egy sem lenne, szóval tök mindegy, akár a /dev/null-ra is küldhetné a filerendszer, szóval nem igazán támogatott a RAID-5/6. Már viszonylag rég volt viszonylag stabilnak tűnő állapotban (volt, aki állítólag legalább 1 éve használta), mikor használni próbáltam, de aztán kiderült, hogy tele van végzetes hibákkal, amikbe én bele is futottam (azóta is léteznek, nem prioritás a javításuk, de legalább már dokumentálták).

  Az extra hajlam és érzékenység a töredezettségre inkább csak olyan dolog, amit "tájékoztató és építő jelleggel" próbálok hangoztatni, nem olyan, ami miatt ne lehetne használni, hisz legalább működik a defrag és metadata balance (elvileg hibátlanul), amiket lehet automatizálni és az IO ütemezéssel csökkenthető az esetleges negatív mellékhatása is (bár gyakorlati szempontból ez lehetne alapszolgáltatás [mint pl. a zfs-nél a scrub-nak dedikált IO ütemező queue], de ez már részletkérdés, morogni lehet rajta, nem vizet választani vele).

  Amúgy igen. nem biztos, hogy ha szétszedem őket, akkor a szóló HDD-re is Btrfs megy, az talán EXT4 lesz (akár journal nélkül). Bár ezt már fejtegettem fentebb, hogy lényegében majdnem mindegy ilyen szempontból (csak a hibás RAID profilokra nincs gyógyír, minden másra igen és egyik filerendszer sem tökéletes más szempontból sem).

  Tudtommal nincs most ingyen semmi, ami olyan jellegű garanciákat kínál a konzisztenciára, mint a Btrfs és ZFS. Minden más vagy hagyományos RAID checksum-ok nélkül, vagy gyakorlatilag egy hagyományos, vagy checksum-olással kiegészített, esetleg paritásra épülő "okos backup" (pl. paritás nélkül ír fel először mindent, aztán kiegészíti a háttérben paritással vagy redundanciával és akár checksum-al is, de ez nem egy tranzakción belül történik, hanem későbbre tolva...). Ezektől ilyen szempontból szerintem minden visszalépés, vagy esetleg ugyan ez, csak más formában, de akkor olyanban, ami számomra nem tetszik, bonyolultabb, és/vagy elérhetetlen is (mint néhány speciális szerverekbe szánt megoldás, amit legfeljebb említésből ismerek, a működése "titkos" is vagy legalább is irreleváns, mert én úgysem fogom használni, főleg nem itthon).

Új hozzászólás Aktív témák