abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×

včera 20:22 | Nová verze

Před měsícem byla vydána Fedora 27 ve dvou edicích: Workstation pro desktopové a Atomic pro cloudové nasazení. Fedora Server byl "vzhledem k náročnosti přechodu na modularitu" vydán pouze v betaverzi. Finální verze byla naplánována na leden 2018. Plán byl zrušen. Fedora 27 Server byl vydán již dnes. Jedná se ale o "klasický" server. Modularita se odkládá.

Ladislav Hagara | Komentářů: 0
včera 10:22 | Zajímavý článek

Lukáš Růžička v článku Kuchařka naší Růži aneb vaříme rychlou polévku z Beameru na MojeFedora.cz ukazuje "jak si rychle vytvořit prezentaci v LaTeXu, aniž bychom se přitom pouštěli do jeho bezedných hlubin".

Ladislav Hagara | Komentářů: 12
včera 07:22 | Komunita

Od 26. do 29. října proběhla v Bochumi European Coreboot Conference 2017 (ECC'17). Na programu této konference vývojářů a uživatelů corebootu, tj. svobodné náhrady proprietárních BIOSů, byla řada zajímavých přednášek. Jejich videozáznamy jsou postupně uvolňovány na YouTube.

Ladislav Hagara | Komentářů: 0
11.12. 19:22 | Nová verze

Ondřej Filip, výkonný ředitel sdružení CZ.NIC, oznámil vydání verze 2.0.0 open source routovacího démona BIRD (Wikipedie). Přehled novinek v diskusním listu a v aktualizované dokumentaci.

Ladislav Hagara | Komentářů: 0
11.12. 09:22 | Pozvánky

V Praze dnes probíhá Konference e-infrastruktury CESNET. Na programu je řada zajímavých přednášek. Sledovat je lze i online na stránce konference.

Ladislav Hagara | Komentářů: 2
9.12. 20:11 | Nová verze

Byl vydán Debian 9.3, tj. třetí opravná verze Debianu 9 s kódovým názvem Stretch a Debian 8.10, tj. desátá opravná verze Debianu 8 s kódovým názvem Jessie. Řešeny jsou především bezpečnostní problémy, ale také několik vážných chyb. Instalační média Debianu 9 a Debianu 8 lze samozřejmě nadále k instalaci používat. Po instalaci stačí systém aktualizovat.

Ladislav Hagara | Komentářů: 2
9.12. 00:44 | Nová verze

Po 6 měsících vývoje od vydání verze 0.13.0 byla vydána verze 0.14.0 správce balíčků GNU Guix a na něm postavené systémové distribuce GuixSD (Guix System Distribution). Na vývoji se podílelo 88 vývojářů. Přibylo 1 211 nových balíčků. Jejich aktuální počet je 6 668. Aktualizována byla také dokumentace.

Ladislav Hagara | Komentářů: 4
8.12. 21:33 | Nová verze

Po půl roce vývoje od vydání verze 5.9 byla vydána nová stabilní verze 5.10 toolkitu Qt. Přehled novinek na wiki stránce. Současně byla vydána nová verze 4.5.0 integrovaného vývojového prostředí (IDE) Qt Creator nebo verze 1.10 nástroje pro překlad a sestavení programů ze zdrojových kódů Qbs.

Ladislav Hagara | Komentářů: 0
7.12. 11:11 | Komunita

Naprostá většina příjmů Mozilly pochází od výchozích webových vyhledávačů ve Firefoxu. Do konce listopadu 2014 měla Mozilla globální smlouvu se společností Google. Následně bylo místo jedné globální smlouvy uzavřeno několik smluv s konkrétními vyhledávači pro jednotlivé země. V USA byla podepsána pětiletá smlouva s vyhledávačem Yahoo. Dle příspěvku na blogu Mozilly podala společnost Yahoo na Mozillu žalobu ohledně porušení této

… více »
Ladislav Hagara | Komentářů: 0
7.12. 05:55 | Zajímavý článek

V Londýně probíhá konference věnovaná počítačové bezpečnosti Black Hat Europe 2017. Průběžně jsou zveřejňovány prezentace. Videozáznamy budou na YouTube zveřejněny o několik měsíců. Zveřejněna byla například prezentace (pdf) k přednášce "Jak se nabourat do vypnutého počítače, a nebo jak v Intel Management Engine spustit vlastní nepodepsaný kód". Dle oznámení na Twitteru, aktualizace vydaná společností Intel nevylučuje možnost útoku.

Ladislav Hagara | Komentářů: 5
Jak se vás potenciálně dotkne trend odstraňování analogového audio konektoru typu 3,5mm jack z „chytrých telefonů“?
 (8%)
 (1%)
 (1%)
 (1%)
 (75%)
 (14%)
Celkem 963 hlasů
 Komentářů: 45, poslední 1.12. 19:00
    Rozcestník

    Systém souborů Btrfs - funkce send/receive a ioctl

    6. 3. 2014 | Luboš Doležel | Různé | 3269×

    V minulých dílech seriálu jsme pokryli většinu funkčnosti tohoto moderního systému souborů. Tento článek je tedy posledním dílem a pokrývá několik zbytků. Podíváme se na funkčnost send/receive a na některé dostupné ioctl().

    Obsah

    Send/receive

    link

    Pomocí podjednotek a snapshotů je možné udělat jednoduché schéma pro tvorbu přírůstkových záloh. Například tak, že použijeme rsync k tomu, aby záložní systém souborů vypadal jako originál, a pak uděláme snapshot zálohy, aby byl zachován stav v daný čas. Tento přístup je poměrně efektivní; rsync zkopíruje pouze změny (přeskočí nezměněné soubory) a každý snapshot uchová tyto změny bez kopírování nezměněných dat. Tímto způsobem můžeme uchovávat docela rozsáhlou historii ve snadno přístupné podobě.

    Existuje ale i jiný způsob, jak dělat zálohy, pokud jsou zdrojový a cílový systém souborů oba Btrfs. V tomto případě se dá mechanismus send/receive použít k optimalizaci celého procesu. Nejprve si uděláme snapshot původního systému souborů:

    btrfs subvolume snapshot -r zdrojová-podjednotka název-snapshotu
    

    Název snapshotu by pravděpodobně mohl obsahovat i časové razítko, jelikož celý mechanismus závisí na existenci snapshotů v čase každé inkrementální zálohy. Počáteční snapshot je pak okopírován na záložní jednotku příkazem:

    cd záložní-systém-souborů
    btrfs send cesta-k-snapshotu | btrfs receive .
    

    Tato operace, která přenese celý snapshot, může chvíli trvat, hlavně když je zdrojový systém souborů velký. Je to také znatelně pomalejší než použití rsync nebo dvojice příkazů tar pro přenos do cílového systému souborů. Použití jednoho z těchto alternativních způsobů by mohlo fungovat, ale používání send/receive zajistí, že je vše připraveno tak, jak to tyto příkazy Btrfs očekávají.

    Pozor na to, že když zdrojový snapshot není jen ke čtení, tak s ním btrfs send odmítne pracovat. Zdá se, že pro dodatečné nastavení příznaku jen ke čtení na existujícím snapshotu nemá btrfs žádný povel, ale pokud je to potřeba, pak je samozřejmě jednoduché udělat nový snapshot jen ke čtení ze zapisovatelného snapshotu.

    Jakmile máme na cílovém systému souborů počáteční kopii, pak už jde přírůstkové zálohy dělat tak, že na zdrojovém systému souborů uděláme nový snapshot a pak spustíme příkaz:

    cd záložní-systém-souborů
    btrfs send -p cesta-k-předchozímu-snapshotu cesta-k-novému snapshotu | btrfs receive .
    

    Díky příznaku -p odešle btrfs send jen soubory (nebo části souborů), které se změnily od vytvoření předchozího snapshotu; pozor na to, že předchozí snapshot musí na záložním systému souborů existovat také. Na rozdíl od počátečního kopírování jsou přírůstkové operace send vcelku rychlé – mnohem rychlejší než používání příkazu jako rsync k nalezení a odeslání změněných souborů. Proto se dá používat k implementaci nenáročného zálohovacího mechanismu, který může běžet mnohokrát denně.

    K plnému využití této funkčnosti bude ale asi potřeba nějaké skriptování. Například není žádoucí nechávat si na zdrojovém systému souborů všechny snapshoty, hlavně pokud se místa nedostává. Ale je nezbytné nechat si každý snapshot do doby, než bude provedena následující přírůstková operace send; použití počátečního snapshotu by vedlo ke zbytečnému kopírování spousty dat. Dá se předpokládat, že časem vzniknou rozumně uživatelsky přívětivé nástroje použitelné pro automatizaci těchto úloh.

    Povely přes ioctl()

    link

    Jako většina komplexních linuxových systémů souborů taktéž Btrfs podporuje řadu ioctl() specifických pro tento systém souborů. Tyto příkazy jsou zpravidla naprosto nedokumentované; člověk se musí pohrabat ve zdrojovém kódu (kde těch komentářů také mnoho není), aby je nalezl a pochopil, co dělají. Tento článek nenahrazuje řádnou dokumentaci, ale několik zajímavých povelů vám ukáže.

    Většina příkazů specifických pro Btrfs provádí operace, které jsou přístupné přes nástroj btrfs. Proto tam najdeme příkazy pro správu podjednotek a snapshotů, zařízení apod. Ve většině případů je nástroj btrfs ideálním nástrojem pro provádění těchto příkazů, proto se o těchto bavit nebudeme. Za pozornost stojí, že několik těchto příkazů existuje v několika verzích; první verze neměla pole (typicky flags), které bylo doplněno v druhé verzi.

    Struktury a konstanty pro všechny příkazy ioctl() na Btrfs najdeme v <linux/btrfs.h>; na některých distribucích může být potřeba nainstalovat si příslušný vývojový (-dev) balíček, abychom tento hlavičkový soubor měli.

    • Klonování souborů. Copy-on-write mechanismus Btrfs je možné používat k vytváření kopií, které sdílejí příslušné úložiště dat souboru, ale přesto se chovají jako nezávislé soubory. Soubor, který je takto „naklonován“, se bude chovat jako pevný odkaz (hard link), dokud nebudou ani originál ani kopie změněny; jakmile dojde ke změně, mechanismus COW okopíruje upravené bloky, čímž dojde k odchýlení těchto souborů. Vytvoření klonu souboru je otázkou jednoduchého volání:

      status = ioctl(dest, BTRFS_IOC_CLONE, src);

      Kde dest a src označují dvojici souborů, nad kterými se má pracovat; dest musí být otevřené a oba soubory se musejí nacházet na stejném systému souborů Btrfs.

      Pro vytvoření klonu části souboru nejprve naplníme takovouto strukturu:

      struct btrfs_ioctl_clone_range_args {
      	__s64 src_fd;
      	__u64 src_offset, src_length;
      	__u64 dest_offset;
      };
      

      Strukturu pak předáme jako argument povelu BTRFS_IOC_CLONE_RANGE:

      status = ioctl(dest, BTRFS_IOC_CLONE_RANGE, &args);

      Stejně jako u BTRFS_IOC_CLONE se cílový soubor předává jako první argument ioctl().

      Všimněte si, že funkce klonování je dostupná i na aktuálních linuxových systémech skrze volbu --reflink příkazu cp.

    • Explicitní flush. Stejně jako na jiných systémech souborů i Btrfs udělá flash nezapsaných dat při voláních fsync() nebo fdatasync(). Synchronizaci můžeme zahájit i explicitně pomocí:

      u64 transid;
      
      status = ioctl(fd, BTRFS_IOC_START_SYNC, &transid);
      

      Toto zahájí operaci flush na systému souborů, který obsahuje fd, ale nebude se čekat na dokončení. Volitelný argument transid bude nastaven na interní číslo transakce odpovídající požadované operaci flush. Pokud by bylo potřeba počkat na dokončení, můžeme tak učinit pomocí:

      status = ioctl(fd, BTRFS_IOC_WAIT_SYNC, &transid);

      transid zde musí pocházet z volání BTRFS_IOC_START_SYNC. Bez něj se bude čekat na dokončení libovolné aktuální transakce.

    • Řízení transakcí. Operace flush může být použita aplikací, která si chce být jistá, že je jedna transakce dokončena, než začne dělat něco dalšího. Programátoři, kteří ale rádi žijí na hraně, mohou ovšem použít povely BTRFS_IOC_TRANS_START a BTRFS_IOC_TRANS_END (bez argumentů) k explicitnímu zahájení a ukončení transakcí na systému souborů. Všechny operace na systému souborů provedené mezi těmito voláními budou ostatním procesům viditelné atomicky; částečně provedené transakce vidět nebudou.

      Třebaže tato funkce vypadá užitečně, je nutné vzít v potaz komentář ze souboru fs/btrfs/ioctl.c:

      /*
       * existuje řada způsobů, jak mohou volání trans_start a trans_end vést
       * k deadlocku. Měly by být používány jen aplikacemi, kterým stroj v podstatě
       * patří a které opravdu do hloubky rozumí všem možným deadlockům a problémům
       * s enospc.
       */
      

      Většina vývojářů asi postrádá „porozumění do hloubky“ ohledně toho, co se na Btrfs může pokazit. Navíc není jak zrušit transakci; takže když aplikace zhavaruje vprostřed transakce, transakce bude dokončena jádrem a všechna práce udělaná před pádem bude vidět. Proto správnou odpovědí všem vývojářům, kteří zvažují využití této funkce, je téměř s jistotou „nedělejte to“. Kdokoliv, kdo se o to bude snažit, bude stejně muset mít právo CAP_SYS_ADMIN.

    Btrfs obsahuje řadu dalších povelů ioctl() podporovaných na Btrfs, ale jak bylo zmíněno výše, většinu z nich je asi lepší použít přes nástroj btrfs. Zvědavci je mohou najít na konci souboru fs/btrfs/ioctl.c ve stromu jádra.

    Závěr seriálu

    link

    Tímto je seriál o Btrfs u konce. Většina funkčnosti nabízené tímto systémem souborů byla v rámci celkem pěti článků popsána. Ačkoliv má několik vývojářů nápady na další zajímavé funkce, většina z nich se do hlavní řady jádra pravděpodobně brzy nedostane; namísto toho se teď vývoj upírá směrem ke stabilnímu a výkonnému systému souborů.

    Jen málo znalých vývojářů je teď toho názoru, že je Btrfs připravené k produkčnímu nasazení, takže práce na stabilizaci a výkonu ještě nějakou dobu potrvají. Navzdory tomu čím dál více uživatelů Btrfs zkouší a i díky tomu je Btrfs více prověřené. I když je obtížné dělat podobné odhady, tak se dá říci, že za rok nebo dva by Btrfs mohl být přijímán jako systém souborů produkční kvality pro čím dál více situací.

           

    Hodnocení: 100 %

            špatnédobré        

    Nástroje: Tisk bez diskuse

    Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

    Komentáře

    Vložit další komentář

    6.3.2014 06:50 benghi
    Rozbalit Rozbalit vše Re: Systém souborů Btrfs - funkce send/receive a ioctl
    Send/receive je úžasná věc, jelikož to podle mýho půjde vysypat na pásku, blicí disk či do fajlu. Zvlášť na pásce mi to společně s inkrementálním zálohováním připadá úžasný.
    6.3.2014 17:26 luky
    Rozbalit Rozbalit vše klonovani
    Z toho popisu my vyplyva, ze klonovane soubory budou mit stejny inode, coz mi prijde nezadujici - pokud je napriklad zataruju a pak roztaruju, tak nedostanu 2 kopie, ale 2 hardlinkovane soubory.
    6.3.2014 21:28 Filip Jirsák
    Rozbalit Rozbalit vše Re: klonovani
    To by nemohlo fungovat, ne? Když pak jeden z klonů souboru změním, měly by dva různé soubory stejný inode - a to podle mne nejde. Podle mne klonování naopak znamená, že jsou dva inode, které ale do první změny sdílí stejné datové bloky.
    pavlix avatar 6.3.2014 21:57 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: klonovani
    Já si hlavně myslím, že z toho textu nic takového nevyplývá.
    Já už tu vlastně ani nejsem. Abclinuxu umřelo.
    7.3.2014 12:48 luky
    Rozbalit Rozbalit vše Re: klonovani
    ... Soubor, který je takto „naklonován“, se bude chovat jako pevný odkaz (hard link), dokud ...
    pavlix avatar 7.3.2014 15:51 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: klonovani
    Chápu to tak, že právě to slovo dokud a co za ním následuje, jasně ukazuje na to, že nemůžou sdílet inode.
    Já už tu vlastně ani nejsem. Abclinuxu umřelo.
    7.3.2014 17:05 Filip Jirsák
    Rozbalit Rozbalit vše Re: klonovani
    Bude se chovat jako pevný odkaz, ne bude to pevný odkaz. Znamená to, že bude mít klíčové vlastnosti stejné, jako pevný odkaz - v tomto případě to, že se při vytvoření nic nekopíruje a kopie nezabírá žádné nové místo na disku.
    7.3.2014 18:02 luky
    Rozbalit Rozbalit vše Re: klonovani
    Bude se chovat jako pevný odkaz, ne bude to pevný odkaz. Znamená to, že bude mít klíčové vlastnosti stejné, jako pevný odkaz - v tomto případě to, že se při vytvoření nic nekopíruje a kopie nezabírá žádné nové místo na disku.
    Prave ze ne, kopie musi spotrebovat jeden inode, jinak nastane ten problem, co jsem popsal.
    pavlix avatar 7.3.2014 18:58 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: klonovani
    O tom se nikdo nepře ;).
    Já už tu vlastně ani nejsem. Abclinuxu umřelo.
    7.3.2014 21:11 luky
    Rozbalit Rozbalit vše Re: klonovani
    V tom pripade se to ale vubec nechova jako hardlink
    8.3.2014 08:41 Filip Jirsák
    Rozbalit Rozbalit vše Re: klonovani
    Taksi to zkuste. Naklonujte si na btrfs soubor, a uvidíte, že po klonování nebudete mít datové bloky souboru na disku dvakrát (jako u obyčejného kopírování), ale jednou (jako u hardlinku).
    pavlix avatar 9.3.2014 15:14 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: klonovani
    A na vyjádření názoru, že sdílení datových bloků na disku nepovažuješ za dostatečnou podobnost s hardlinkem, jsi napsal už asi pět komentářů? Tomu říkám efektivní komunikace.
    Já už tu vlastně ani nejsem. Abclinuxu umřelo.
    7.3.2014 12:58 luky
    Rozbalit Rozbalit vše Re: klonovani
    No prave, IMO se novy inode musi naalokovat hned a ne az kdyz se soubor zmeni.
    9.3.2014 22:41 ebik
    Rozbalit Rozbalit vše Re: klonovani
    inode je pouze struktura obsahujici odkaz(y) na datove bloky. Inody budou mit ruzne. Datove bloky budou mit spolecne. Pokud do jednoho datoveho bloku jednoho souboru nekdo neco zapise, tak se predela ten odkaz na novy datovy blok a tam se zapise zmena. (Copy on write). Takze z pohledu OS jsou to ruzne soubory se vsim vsudy, pouze FS se stara o "kompresi" pomoci deduplikace dat. Chova se to pak podobne jako komprimovany FS: kdyz mas soubor velikosti 10MB a prepises ho jinymi daty o stejne velikosti, tak se zmeni velikost volneho mista (klidne muze najednou dojit).
    7.3.2014 10:27 Honz
    Rozbalit Rozbalit vše Re: klonovani
    Správné by bylo napast " s toho popysu my viplívá"...
    7.3.2014 18:51 čavo
    Rozbalit Rozbalit vše Pripájanie RAID1 btrfs
    Mám problém s pripájaním BTRFS, na ktorom sú data RAID1
    # btrfs fi df /home/
    Data, RAID1: total=268.84GiB, used=182.90GiB
    System, RAID1: total=64.00MiB, used=48.00KiB
    System, single: total=4.00MiB, used=0.00
    Metadata, RAID1: total=18.00GiB, used=426.36MiB
    
    # mount | grep home
    /dev/sda2 on /home type btrfs (rw)
    
    niekedy sa pripája tak cez mount /dev/sda2 a niekedy cez mount /dev/sdb2 a nikdy neviem dopredu po štarte, cez ktoré meno sa má pripájať (cez to druhé sa s chybou nepripojí). LABEL a UUID mi prideluje jadro po štarte náhodne ku jednému z nich a najčastejšie ku tomu, cez ktorý sa to nedá pripojiť.

    Samozrejme podľa zákonu maslového chleba, to je tak, že zakaždým je to presne ten druhý ako napíšem do /etc/fstab (už som skúšal aj LABEL a UUID), ale podľa pozorovaní sa po reštarte automaticky pripojí len v asi 10% prípadov.

    Nepoužívam initrd a vo stab som priebežne vyskúšal tieto možnosti:
    #/dev/sda2              /home           btrfs           noatime,nodiratime,autodefrag,noacl     1 2
    #/dev/sdb2              /home           btrfs           noatime,nodiratime,autodefrag,noacl     1 2
    #LABEL=home             /home           btrfs           noatime,nodiratime,autodefrag,noacl     1 2
    UUID=fba01cbb-f374-4815-a9da-0f98c27fee21       /home   btrfs   noatime,nodiratime,autodefrag,noacl     1 2
    #/dev/sdb2              /home           btrfs           noatime,nodiratime,autodefrag,noacl,device=/dev/sda2,device=/dev/sdb2               1 2
    #/dev/sda2              /home           btrfs           noatime,nodiratime,autodefrag,noacl,device=/dev/sda2,device=/dev/sdb2               1 2
    
    Prakticky som vyskúšal všetky možné zápisy čo som našiel na internete. Len ten stroj nevypínam často a tak ma štve, keď po reštarte sa musím potom pomocou ssh pripojiť (špeciálne som si musel vytvorit používateľa mimo /home), ručne pripojiť disk s /home a poreštartovať služby, ktoré sú na prístupnosti /home závislé.

    Poznáte niekto iný zázračný postup ako to vyriešiť? Je možné, že mám ten súborový systém zle vytvorený. Mätie ma hlavne položka „System, single: ...“
    7.3.2014 19:01 čavo
    Rozbalit Rozbalit vše Re: Pripájanie RAID1 btrfs
    Ups. Zabudol som pripísať. Používam aktualizované Gentoo.
    # uname -a
    Linux octopus 3.10.25-gentoo #1 SMP Tue Feb 4 07:31:51 CET 2014 x86_64 AMD A8-5600K APU with Radeon(tm) HD Graphics AuthenticAMD GNU/Linux
    
    # equery l btrfs\*
     * Searching for btrfs* ...
    [IP-] [  ] sys-fs/btrfs-progs-3.12-r1:0/0
    
    9.3.2014 13:02 jas | skóre: 13 | blog: blag
    Rozbalit Rozbalit vše Re: Pripájanie RAID1 btrfs

    To, ze sa niekedy meni pismeno disku je normalne. Problem je, ze niekedy trva dlhsie jednemu disku kym sa inicializuje a inokedy druhemu. Presne na riesenie podobnych problemov vzniklo UUID, kedze to je celkom bezny problem. Problem moze byt napr. v tom, ze init system necaka dostatocne dlho, kym zacne pripajat disky.

    Skuste porovnat casove znamky jadra (dmesg), kedy ukaze, ze sa spamatal jeden, kedy druhy disk, kedy su tam nejake hlasky o tom, ze sa pripaja disk a pod. Ak sa pozadovany disk spamata neskor, tak je problem skutocne v init systeme. Riesenie moze byt napr. napisat si init script, ktory caka kym jadro spostredkuje dany disk (cca len nieco ako "while test ! -f /dev/disk/by-uuid/$UUID;do sleep 0.1;done")

    Alternativne by mohol byt problem s duplikovanymi UUID a pod. (predsa len, je to raid 1). Co vypisuje prikaz blkid? Co vypisuje jadro, ked pripajanie disku padne?

    Este jedna vec, netusim ako presne sa riesi v linuxe hw raid (a drzim sa hesla: 'hw raid: nikdy' prave kvoli mnozstvu bugov, co su v ich firmwaroch a neriesia sa), ale nevytvari jadro nahodou aj /dev/mdX zariadenie, ktore sa da normalne pripojit?

    10.3.2014 10:18 čavo
    Rozbalit Rozbalit vše Re: Pripájanie RAID1 btrfs
    Neviem či sa disky prečíslovávajú, ale klasický md v jadre problém nemá. (nemám tam nikde HW RAID a mám tam aj klasický RAID z jadra), tento RAID je z BTRFS (keďže je to článok o btrfs)
    # mount | column -t
    rootfs       on  /                      type  rootfs    (rw)
    /dev/md0     on  /                      type  jfs       (rw,noatime)
    devtmpfs     on  /dev                   type  devtmpfs  (rw,relatime,size=7890724k,nr_inodes=1972681,mode=755)
    proc         on  /proc                  type  proc      (rw,relatime)
    tmpfs        on  /run                   type  tmpfs     (rw,nosuid,nodev,relatime,size=1578228k,mode=755)
    devpts       on  /dev/pts               type  devpts    (rw,nosuid,noexec,relatime,gid=5,mode=620)
    shm          on  /dev/shm               type  tmpfs     (rw,nosuid,nodev,noexec,relatime)
    sysfs        on  /sys                   type  sysfs     (rw,nosuid,nodev,noexec,relatime)
    debugfs      on  /sys/kernel/debug      type  debugfs   (rw,nosuid,nodev,noexec,relatime)
    cgroup_root  on  /sys/fs/cgroup         type  tmpfs     (rw,nosuid,nodev,noexec,relatime,size=10240k,mode=755)
    openrc       on  /sys/fs/cgroup/openrc  type  cgroup    (rw,nosuid,nodev,noexec,relatime,release_agent=/lib64/rc/sh/cgroup-release-agent.sh,name=openrc)
    cpu          on  /sys/fs/cgroup/cpu     type  cgroup    (rw,nosuid,nodev,noexec,relatime,cpu)
    /dev/md1     on  /mnt/portage           type  ext4      (rw,noatime)
    /dev/sda2    on  /home                  type  btrfs     (rw)
    
    Čiže sú dva samostané disky (partície) /dev/sda2 a /dev/sdb2, pomocou btrfs prepojené do RAID1. Akurát, že btrfs nevytvára nový názov RAID-ovaného poľa a tak sa to pripája pomocou mena jedného z diskov. Problém je, že nemôžem použiť, ktorékoľvek meno z tých diskov, ale určité konkrétne a ešte ďalší problém je, že nedokážem predikovať, ktoré s tých mien mám použiť, pretože sa nezastupujú, ale cez to druhé sa to pripojiť nedá. UUID a LABEL (majú oba disky nastavené, predpokladám), ale „zväčša“ je to v jadre pridelené práve tomu, cez ktorý sa mi to nedarí pripojiť.

    11.3.2014 19:14 jas | skóre: 13 | blog: blag
    Rozbalit Rozbalit vše Re: Pripájanie RAID1 btrfs

    UUID a label neprideluje jadro, su zapisane na disku (sucast hlaviciek file systemu). UUID je nahodne generovane user-space aplikaciou (v tomto pripade mkfs.btrfs) zatial co LABEL nastavuje uzivatel (neviem aky prikaz je na to pri btrfs, nepouzivam btrfs).

    Kazdopadne pozeral som navody ako vlastne ten raid v btrfs funguje a moj typ je jednoduchy: jeden disk obsahuje len naklonovane metadata a ziadne data (alebo naopak, len data), zatial co druhy obsahuje oboje a preto aj ide pripojit.

    Vystup prikazov 'blkid' (pod rootom, inak nezobrazi detaily o systemovych particiach, ale len uzivatelovych -- tj. zvacsa nic) a 'btrfs filesystem show' by v tomto pomohol omnoho viac nez vypis mount.

    Pouzilo sa pri vytvarani mkfs.btrfs -m raid1 -d raid1 /dev/<1st> /dev/<2nd> alebo sa -m ci -d zabudlo?

    9.3.2014 22:57 ebik
    Rozbalit Rozbalit vše Re: Pripájanie RAID1 btrfs
    Asi mas rozbity neco v konfiguraci toho raidu. Sice btrfs nerozumim, ale RAID1 by snad mel jit pripojit pres oba disky, jinak je ti na houby. (Kdyz ti odejde do vecnych lovist ten disk, pres ktery to mountis, jak se dostanes na ten druhy?)
    10.3.2014 10:00 čavo
    Rozbalit Rozbalit vše Re: Pripájanie RAID1 btrfs
    To je to, že asi, pretože ani po nabehnutí systému sa to neda pripojiť cez ktorýkoľvek disk, ako to je písane v návodoch. Lenže som neprišiel na to, čo som zle vygeneroval. tento disk si teraz nemôžem len tak zrušiť a skúšať na ňom, tak to asi bude ešte skúšať na iných diskoch a uvidím, či ta to bude rovnako správať.

    Založit nové vláknoNahoru

    ISSN 1214-1267   www.czech-server.cz
    © 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.