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í
×
    dnes 21:22 | IT novinky

    Ministerstvo pro místní rozvoj (MMR) jako první orgán státní správy v Česku spustilo takzvaný „bug bounty“ program pro odhalování bezpečnostních rizik a zranitelných míst ve svých informačních systémech. Za nalezení kritické zranitelnosti nabízí veřejnosti odměnu 1000 eur, v případě vysoké závažnosti je to 500 eur. Program se inspiruje přístupy běžnými v komerčním sektoru nebo ve veřejné sféře v zahraničí.

    Ladislav Hagara | Komentářů: 0
    dnes 16:22 | IT novinky

    Vláda dne 16. července 2025 schválila návrh nového jednotného vizuálního stylu státní správy. Vytvořilo jej na základě veřejné soutěže studio Najbrt. Náklady na přípravu návrhu a metodiky činily tři miliony korun. Modernizovaný dvouocasý lev vychází z malého státního znaku. Vizuální styl doprovází originální písmo Czechia Sans.

    Ladislav Hagara | Komentářů: 8
    dnes 15:33 | Upozornění

    Vyhledávač DuckDuckGo je podle webu DownDetector od 2:15 SELČ nedostupný. Opět fungovat začal na několik minut zhruba v 15:15. Další služby nesouvisející přímo s vyhledáváním, jako mapyAI asistent jsou dostupné. Pro některé dotazy během výpadku stále funguje zobrazování například textu z Wikipedie.

    bindiff | Komentářů: 4
    dnes 13:33 | Bezpečnostní upozornění

    Více než 600 aplikací postavených na PHP frameworku Laravel je zranitelných vůči vzdálenému spuštění libovolného kódu. Útočníci mohou zneužít veřejně uniklé konfigurační klíče APP_KEY (např. z GitHubu). Z více než 260 000 APP_KEY získaných z GitHubu bylo ověřeno, že přes 600 aplikací je zranitelných. Zhruba 63 % úniků pochází z .env souborů, které často obsahují i další citlivé údaje (např. přístupové údaje k databázím nebo cloudovým službám).

    Ladislav Hagara | Komentářů: 4
    dnes 00:11 | Nová verze

    Open source modální textový editor Helix, inspirovaný editory Vim, Neovim či Kakoune, byl vydán ve verzi 25.07. Přehled novinek se záznamy terminálových sezení v asciinema v oznámení na webu. Detailně v CHANGELOGu na GitHubu.

    Ladislav Hagara | Komentářů: 0
    včera 20:44 | IT novinky

    Americký výrobce čipů Nvidia získal od vlády prezidenta Donalda Trumpa souhlas s prodejem svých pokročilých počítačových čipů používaných k vývoji umělé inteligence (AI) H20 do Číny. Prodej těchto čipů speciálně upravených pro čínský trh by tak mohl být brzy obnoven, uvedla firma na svém blogu. Americká vláda zakázala prodej v dubnu, v době eskalace obchodního sporu mezi oběma zeměmi. Tehdy to zdůvodnila obavami, že by čipy mohla využívat čínská armáda.

    Ladislav Hagara | Komentářů: 10
    včera 17:22 | Nová verze

    3D software Blender byl vydán ve verzi 4.5 s prodlouženou podporou. Podrobnosti v poznámkách k vydání. Videopředstavení na YouTube.

    Ladislav Hagara | Komentářů: 0
    14.7. 22:22 | Komunita

    Open source webový aplikační framework Django slaví 20. narozeniny.

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

    V Brestu dnes začala konference vývojářů a uživatelů linuxové distribuce Debian DebConf25. Na programu je řada zajímavých přednášek. Sledovat je lze online.

    Ladislav Hagara | Komentářů: 0
    14.7. 11:33 | IT novinky

    Před 30 lety, tj. 14. července 1995, se začala používat přípona .mp3 pro soubory s hudbou komprimovanou pomocí MPEG-2 Audio Layer 3.

    Ladislav Hagara | Komentářů: 28
    Jaký je váš oblíbený skriptovací jazyk?
     (58%)
     (27%)
     (7%)
     (3%)
     (0%)
     (1%)
     (4%)
    Celkem 402 hlasů
     Komentářů: 16, poslední 8.6. 21:05
    Rozcestník

    Administrace komentářů

    Jste na stránce určené pro řešení chyb a problémů týkajících se diskusí a komentářů. Můžete zde našim administrátorům reportovat špatně zařazenou či duplicitní diskusi, vulgární či osočující příspěvek a podobně. Děkujeme vám za vaši pomoc, více očí více vidí, společně můžeme udržet vysokou kvalitu AbcLinuxu.cz.

    Příspěvek
    3.7.2024 13:12 Andrej | skóre: 51 | blog: Republic of Mordor
    Rozbalit Rozbalit vše Re: Přesunutí BTRFS snapshotu na jiné místo
    …jeden sendne a druhý to bude přijímat ?

    Rozhodně NE. send a receive je potřeba pouze pro kopírování mezi různými FS; v rámci jednoho FS je to naprosto zbytečný overkill.

    Přesun a přejmenování subvolume — dle libosti!

    Subvolume lze v rámci jednoho filesystému přesouvat a přejmenovávat skoro jako běžné adresáře. Pojďme si to předvést!

    btrfs subvolume create sub1{,/a} sub2{,/b}
    ls -R sub{1,2}
    

    Jenom tak, čistě bezdůvodně, prohodíme „vnořené“ subvolume — ve skutečnostni nejsou nikam vnořené, viz níže —, nejjednoduším možným způsobem:

    mv sub2/b sub1/
    mv sub1/a sub2/
    ls -R sub{1,2}
    

    A teď to prohodíme zase zpátky, ale schválně jiným způsobem, jenom tak pro zajímavost a pro ilustraci a pro potěšení a pro zábavu a pro dobrý pocit typu „tak teď fakt používám Btrfs“:

    btrfs subvolume snapshot sub1/b sub2/b
    btrfs subvolume snapshot sub2/a sub1/a
    ls -R sub{1,2}
    btrfs subvolume delete sub1/b sub2/a
    ls -R sub{1,2}
    

    A teď ten zbývající bordel zase po sobě uklidíme:

    btrfs subvolume delete sub1{/a,} sub2{/b,}
    

    Subvolume u Btrfs ve skutečnosti nejsou „zahnízděné“!

    Klíčové pozorování z předchozí kapitoly: Zahnízdění do sub1 a sub2 je v tomto případě v podstatě zbytečné. Stejně jako jakékoliv pokusy o hierarchii subvolume.

    Na rozdíl od ZFS, který má paralelní strom subvolume, který přímo nesouvisí s adresářovým stromem souborového systému ani s mout pointy a je hierarchicý, Btrfs nic takového nemá.

    Subvolume a snapshoty v Btrfs (což je z hlediska použití skoro totéž) jsou ploché, bez hierarchie, identifikované pouze pomocí subvolid. Manuálová stránka o tom malinko mlží, ale v podstatě to tam je.

    A subvolume in BTRFS can be accessed in two ways:
    • like any other directory that is accessible to the user
    • like a separately mounted filesystem (options subvol or subvolid)
    In the latter case the parent directory is not visible and accessible. This is similar to a bind mount, and in fact the subvolume mount does exactly that.

    Tady ještě jednoduchý přehled, jak je to s tou atomicitou:

    Btrfs

    ZFS

    reprezentace subvolume z pohledu uživatele

    plochý prostor subvolid, kořenový subvolume lze nastavit pomocí set-default, ostatní mají implicitní mount pointy, které skoro (viz níže) po všech stránkách fungují jako mount -o bind, ne jako mount -o rbind

    stromovitá hierarchie subvolume, nezávislá na samotném souborovém systému, každý uzel v hierarchii má nastavitelný (implicitní) mount point, případně nemusí být namountovaný vůbec

    co představuje hierarchie subvolume

    nic; u Btrfs žádná viditelná hierarchie subvolume není; copy-on-write vztahy mezi různými subvolume a snapshoty (ať už lokálně vytvořenými nebo odzrcadlenými z receive) se uržují automaticky, bez vědomí uživatele

    vztah předek / zadek / potomek v copy-on-write hierarchii, částečně (v určitém smyslu) taky časovou osu, historii, kterou lze pomocí promote trochu přepisovat, asi jako git rebase

    rozsah atomicity snapshotů

    pouze a výhradně pro daný subvolume; další subvolume “uvnitř” jeho adresáře jsou úplně oddělené, neúčastní se snapshotů (daného subvolume), nejsou atomické v rámci snapshotů jejich “mount pointu”, prostě fungují stylem mount -o bind, ne stylem mount -o rbind.

    přes celý podstrom oddělené hierarchie subvolume, bez ohledu na jejich mount pointy a bez ohledu na to, zda jsou namountované; snapshot podstromu hierarchie subvolume je atomický přes všechny jeho pod-uzly

    subvolume a snapshot je totéž

    skoro jo, víceméně

    ne tak úplně, viz příkaz promote

    Kdo nevěří, ať tam běží!

    Cituji z manuálové stránky:

    What should be mentioned early is that a snapshotting is not recursive, so a subvolume or a snapshot is effectively a barrier and no files in the nested appear in the snapshot. Instead there's a stub subvolume (also sometimes empty subvolume with the same name as original subvolume, with inode number 2). This can be used intentionally but could be confusing in case of nested layouts.

    Tady je jednoduchý příklad (ne)atomicity (ne)hierarchických subvolume:

    btrfs subvolume create sub1{,/a}
    touch sub1/a/blah
    btrfs subvolume snapshot sub1 sub2
    

    Tedy ještě jednou: Subvolume (ani snapshoty) u Btrfs nejsou hierarchické; nefunguje to jako oddělená hierarchie subvolume u ZFS:

    ls -Rl sub{1,2}    # <<< sub2/a NENÍ subvolume a NEOBSAHUJE blah
    stat -c%i sub2/a   # <<< 2, přesně jak říká manuálová stránka!
    touch sub2/a/blah  # <<< zamítnuto! tohle není běžný adresář!
    

    Důvod, proč sub2/a není (ani) skutečný adresář (jakým by byl třeba běžný mount point) je předcházení omylům a nesrovnalostem, kdy někdo v daném adresáři buď něco očekává, nebo do něj něco zapisuje atd. Pojďme to zase uklidit! A povšimněme si, že sub2/a není třeba nijak uklízet, protože to není usbvolume:

    btrfs subvolume delete sub1{/a,} sub2
    

    Počkat! Ale co kdybychom chtěli mít také snapshot sub1/a v sub2/a? Inu, museli bychom ho odzrcadlit manuálně a neatomicky. Například:

    btrfs subvolume create sub1{,/a}
    touch sub1/a/blah
    btrfs subvolume snapshot sub1 sub2      # <<< Začátek race window!!1
    rmdir sub2/a                            # <<< Jo! Tohle jako fakt!
    btrfs subvolume snapshot sub1/a sub2/a  # <<< Konec race window!!!
    
    ls -Rl sub{1,2}       # <<< sub2/a JE subvolume a OBSAHUJE blah
    stat -c%i sub{1,2}/a  # <<< subvolid kořene (!= 2) (nedokumentováno)
    
    btrfs subvolume delete sub{1,2}{/a,}    # <<< Teď jsou obě sub{1,2}/a subvolume.
    

    V případě Btrfs se tedy atomicita snapshotů nepropaguje „přes mount point“.

    Je to důležité?

    V mnoha případech to není příliš podstatné; potřeba atomicity přes několik subvolume může svědčit o špatném návrhu adresářové struktury — například použití subvolume tam, kde by měly být obyčejné adresáře.

    Leč pravda je, že ZFS má v tomhle jednom ohledu jakousi drobnou „výhodu“ — nebo přinejmenším feature navíc.

    V tomto formuláři můžete formulovat svou stížnost ohledně příspěvku. Nejprve vyberte typ akce, kterou navrhujete provést s diskusí či příspěvkem. Potom do textového pole napište důvody, proč by měli admini provést vaši žádost, problém nemusí být patrný na první pohled. Odkaz na příspěvek bude přidán automaticky.

    Vaše jméno
    Váš email
    Typ požadavku
    Slovní popis
    ISSN 1214-1267   www.czech-server.cz
    © 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.