Keresés

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

  • janos666

    nagyúr

    válasz bambano #24643 üzenetére

    Szerintem ez az érvelés egy szentimentális elvvel bírálja felül azt az objektív elvet, hogy tényleges előny származhat abból (jobb teljesítmény és/vagy erősebb konzisztencia garanciák válhatnak lehetővé, akár egyszerre), hogy ha egységesen kezelsz egy komplex problémahalmazt (mint a Btrfs és ZFS féle RAID módok, mikor nem teszel közéjük és a tárterület közé semmit, aminek képes és hasznos lehet, ha kiváltja a funkcióját maga a filerendszer driver), mintsem szétszeleteled a potenciálisan egymástól függő (egyedül nem teljesen, vagy csak sokkal nehezebben, kisebb mértékben/bizonyossággal feltárható/megérthető) problémákat külön rétegekre, amik alapfelállásban szándékosan nem is tudnak, és nem is akarnak kommunikálni egymással, hanem mindegyik csak a maga kis dolgát akarja végezni, és nem aggódni olyasmik miatt, hogy lehetett-e volna többet tenni, okosabban eljárni bizonyos esetekben, mert ő csak a saját kis világán belül akar megfelelni a saját kis szabályainak.

    Erre szemléletes lehet egy bürokrácia, ahol több, független, egymással közvetlenül egyedi esetekről nem kommunikáló hatóságnak kell valamit jóváhagynia, és van egy szituáció, mikor a saját szabályaik szerint mind tökéletesen végzik a dolgukat, és a szerencsétlen ember is szabályosan próbál eljárni, de a gyakorlatban mégis akadnak dolgok, amiket lehetetlennek tűnik keresztülvinni, mert A hivatalból elküldik a B-be, B-ből C-be, de C-ből vissza A-ba, viszont az A megint nem áll vele szóba, míg a B-től nincs pecsét, úgyhogy mehetne a végtelenségig megint körbe C-be, és így tovább, míg elfogy a türelem, és/vagy feladja az egészet, vagy esetleg megpróbálja megkerülni a szabályokat.

    A gépeknél nem fog megkönyörülni egy ügyintéző még kenőpénzért sem, hacsak nem kezdik el "hackelni" a rendszert, és kiegészíteni mindenféle speciális kommunikációval az összes réteget, hogy a végén egy még inkább összetákolt lecsó legyen, mint az ilyen "okos" filerendszerek, ahol ez legalább eredeti design elem, nem extra rálapátolás valamire, amit nem erre terveztek.

    Szerintem sokkal előbbre járna már a Btrfs fejlesztés, ha legtöbben így gondolkodnának, bár én úgy sejtem legtöbbeknél nem elvek (főleg nem átgondolt elvek, de még csak nem is szentimentális elvek), hanem sokkal egyszerűbb bináris berögződés a hagyományos rétegzés preferálása (valamikor valahol bevésődött neki, hogy szoftver RAID = szar, hardware RAID = istenség, és nem hajlandó újragondolni, bárhogy és bármivel érvelnek neki, hiába intelligens és tanult ember, ez neki vallós jellegű dolog...).

    Ugyan így, szerintem a Btrfs RAID-5/6 mód is csak azért olyan, amilyen, mert úgy áll hozzá a legtöbb fejlesztő, hogy "egyébként is jobb a 0+1, tehát akkor is azt kéne használni, ha tökéletesen hibátlan lenne az 5/6 mód, így nincs utóbbit értelme fejleszteni".

    (#24645) emvy

    Nekem előbb az jutott volna eszembe hasonló példának, hogy biztos használ iniram-fs/disk előtöltést oda is, ahol teljesen felesleges, mert fix a konfiguráció, így nyugodtan mehetne egy testre szabott monolit kernel, amit nem melegen legóz össze egy előtöltő (ami extra idő boot-oláskor, forgatáskor, konfiguráláskor, illetve extra hibaforrás, mert még egy dolog, amire a tökéletlen emberi rutinnal figyelni kell). De ja, a systemd követel ilyet, szóval ha az megvan, akkor ez is. :D

  • hcl

    titán

    LOGOUT blog

    válasz bambano #24643 üzenetére

    Érteni.
    Hát ha 2 éve fixált formátum, akkor az bizony elég új...Azért az ext filerendszereknek sokkal több ideje volt kiforrni magukat.
    Amúgy az LVM is tud már raidet, az is pont elég gáz - az sem annyira UNIX.

    Egyébként pár dolog mostanában nekem is böki ilyesmik közül a csőröm, hogy mennyire tesz jót a kompatibilitásnak a mostanában bevezetett dolgok közül néhány.

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