Keresés

Hirdetés

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

  • F34R

    nagyúr

    válasz janos666 #3448 üzenetére

    Nos tudd hogy a ZFS mukodik in-built kent is, meg kernel modulkent is. Ugye a wiki a modulos verziot taglalja leginkabb, de kiter arra is ha maskepp akarod hasznalni, akkor el kell oket "kuloniteni" egymastol kulonben osszeakadnak. Mindenkeppen hasznald mellette az Archlinux wiki-jet is, mert tobb mindenre kiternek.
    Igen tud PARTUID alapjan pool-t letrehozni es csatolni is, valoban jo gondolat hogy nem erdemes megtartani a BTRFS-t. Mivel utobbit is az Oracle fejlesztette (sok mas ceg beletrollkodasaval egyetemben) igy vagy az egyiket hasznalnam, vagy a masikat. BTRFS jobb liszensz ugyileg, a kernelhez is jobban illeszkedik, meg kompatibilisebb a jelenlegi felhasznalasra mint a ZFS.
    Ettol fuggetlenul Gentoo.org foruman is van aki a kezdetetkol inkabb ZFS-t hasznal.
    Ket bejegyzest is talasz, egyik konretan a rendszer telepiteset nullarol taglalja [link], a masik meg egy altalanos ismerteto [link].
    En meg mindig az initramfs valtozattal talalkoztam, ezt a legegyszerubb mukodesre birni, es upstream tudod tartani. (ajanlott mindig a legfrissebb zfs csomagokat hasznalni.) Erre csinaltak egy alternativ rendszerindito lemezt is [link]

    Egyet meg tudok, hogy nem epp acelosak a sebessegek ezalatt a fajlrendszer alatt.
    OpenRC az fstab-ra es a localmount-ra hagyatkozik, nekem csak olyan bejegyzesek vannak amik kellenek, a localmount szerviz le van allitva, igy nem akar mindig le-fel csatolni.
    Mondjuk en maradtam volna a grub mellett, de efistub is tud manualisan mountolni kernel line parameterekkel.
    Erre is talasz wiki-t, ha mashol nem Archwiki-ben.

    [ Szerkesztve ]

  • F34R

    nagyúr

    válasz janos666 #3451 üzenetére

    Pont a Genkernel-next-et akartam ajanlani, nekem Archon volt meg inintramfs, meg az elso hasznalatkor Gentoo-n amikor meg nem tudtam kernelt forgatni mukodo modulokkal. Most ahogy igy le van faragva nincs szukseg ra, amugy is lassabb maga a forgatas. Ennek ellenere eszrevetem, hogy vannak olyan teruletek ahol igenis szukseg van ra.

    Dracut-al megjatszanek meg egy probat.
    Csak sajat felelosegre : "At the time of writing, dracut is not marked stable yet, so it may need unmasked before continuing."

    meg egy kis segitseg : [link]

    Egyebkent ajanlott nem Systemd-t hasznalni ebben az esetben, mert 220-as verziotol mar maskepp generalja le.

    "So, after looking into the dracut modules it seems that evolarium is right that zfs-dracut with systemd 220 or newer is broken and a generator script for the sysmount is required to make root on zfs work with dracut and systemd >=220."

    Remelem sikerulni fog :DDD

  • F34R

    nagyúr

    válasz janos666 #3453 üzenetére

    Normal XFS-es vagy EXT4-s raid-et nem probaltal meg, vagy esetleg mar a hagyomanyos megoldasok nem jottek be?
    Egyebkent nekem singe disken volt BTRFS es hiaba kapcsoltam ki cow-t nem sokkal lett gyorsabb, sima szekvencialis felhasznalasra is lassabb volt mint az XFS, torrentnel jobban is toredezett.

    Egyebkent lehet jo hir neked, de van egy masik fajlrendszer ami a BTRFS kis hibait probalja kikuszobolni.
    egyenlore eleg early statusban : [link]

    Azthiszem meg is valaszoltam magamnak a kerdest.

    " I lost terrabytes of data with btrfs on a backup server again and again and again.
    In the end I use ext4 as trustworthy frontend, and btrfs as a unreliable backup. Because ext4 can't beat btrfs when it comes to snapshot/delete. It takes a second to snapshot, and deletes of a snapshotted tree what takes ext4 26 hours is a few minutes on btrfs.
    Another point against btrfs is the insane amount of memory it uses.
    But in the end I hope btrfs will be as trustworthy as ext4 or even as much as reiserfs in the 2.4 kernel series, because btrfs has this insane amount of checking that I really want. Especially in a SOHO environment where my photographs are going on my personal cloud.
    Actually, btrfs should become cloud based... My current attempts will be using an fcoe exported physical volume from another server, together with a local disk. But what if btrfs was running locally *and* remotely, working together for raid 1 storage on non raid disk configurations. The current btrfs implementation should allow something like that with not too much work. I mean: currently raid one is implemented by taking 2 "lower level" individual btree storages and make sure they have the same higher level data in that storage."

    :DDD :DDD

    Probaltal amugy mas disztrot is?

    [ Szerkesztve ]

  • F34R

    nagyúr

    válasz janos666 #3455 üzenetére

    Igen, kimondottan zfs patchsettel elatott kernel nincs, egyik disztro oldalarol sem. Volt hir rola hogy az Ubuntu-ba telepiteskor valaszthato lesz a zfs de csak nem kerult bele mert o szerintuk sem ugy mukodik egyutt a disztrojukkal ahogy ok ezt megalmodtak.
    Gentoo egyebkent mindentol elter, mert eleve mas az osszetetele mint a binaris tarsainak.
    Legtobb initramfs-re epul es systemd az alapertelmezett init rendszer is (80%-ban).
    Solarison kivul meg volna egy tippem, FreeBSD. Meg van meg egy de annak a neve most hirtelen nem jut eszembe.
    Talan ezek meg egy probat megernenek. Ebbe viszont az a hatrany hogy nem tudsz valtani, mert ket fajlrendszer van az UFS meg a ZFS.

    E350 ha jol gondolom? regebben en is olvastam rola hogy a zfs jaratja szepen a cpu-t, de hogy most ez a rossz portolasnak vagy egy bugnak koszonheto, vagy esetleg azert mert tobb layeren megy at es ez feladatigenyes azzal nem torodtem.
    Most akkor jol gondolom azt hogy esetleg SSD-n nem volna olyan tordeles mint egy merevlemezen? Van egy felhasznalo Gentoo forumon aki BTRFS SSD-s Raid-et hasznal egy 850-s EVO-n :P Es azt allitja neki nincs vele semmi gondja.
    Igen ahogy te is mondod Raid5/6 olyan allapotban van hogy nem lehet hasznalni, ezt a hivatalos statusz oldalukon is feltuntetik.

    https://btrfs.wiki.kernel.org/index.php/Status

    Single Disk-re akar SSD-re egyebkent a legjobb meg mindig az Ext4 es az XFS. Tobb lemezen nem probaltam egyiket sem, foleg nem RAID-ben mivel nem rendelkezek egyforma diszkekkel.
    Egyebkent itt ha meglatogatod a nagy linux topikot ott is a "hagyomanyos" modszert fogjak ajanlani.
    Az ingyenes dologra (softraid) es a fizetos (hwraid)-re celoztal, az utobbinak is vannak buktatoi rendesen, igy meg mindig jobb az olcsobb modszert hasznalni, mert azt te is ki tudod kuszobolni.
    Egyebkent ugy veszem eszre hogy a te igenyeidnek inkabb a BTRFS tesz eleget, erdemes mindig upstream tartani, bar ha jol gondolom abbol is a git verzio erkezik hozzad...

  • F34R

    nagyúr

    válasz janos666 #3457 üzenetére

    Eleve megbizhatatlan az SSD hosszabb tavra, foleg adattarolasra. Johetnek az SSD guruk hogy tobbszor volt mar nekik HDD failure mint Flash alapu, de szamomra meg mindig jobb. Mivel koltseghatekonysag celjabol csokkentik a csikszelesseget ataltak TLC-er is hogy kisebb die size-al nagyobb tarhelyet erhessenek el, ez viszont a minoseg rovasara megy. Arrol nem is beszelve hogy egyaltalan nem koltseghatekony.

  • F34R

    nagyúr

    válasz janos666 #3459 üzenetére

    Dist fajlokat szoktam kitorolni, meg a nem kello csomagokat kiszelektalni a world-bol
    eclean-dist --deep
    vim /var/lib/portage/world

    jah es termeszetesen a tmp

    rm * /var/tmp/protage/
    A regi kernel-source-t meg szoktam hagyni.

    rsync vagy tar, en utobbit jobban szeretem.

  • shina

    csendes tag

    válasz janos666 #3570 üzenetére

    Mit próbálsz elérni? A portage tree-t szeretnéd ellenőrizni (azaz az ebuild állományokat), vagy a portage tree Manifest állományaiban lévő hasheket amik a forrás tarballokra vonatkoznak?

    ___________________/\_____________\0/_______

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