Byla vydána nová verze 25.12.30 svobodného multiplatformního video editoru Shotcut (Wikipedie) postaveného nad multimediálním frameworkem MLT. Shotcut je vedle zdrojových kódů k dispozici také ve formátech AppImage, Flatpak a Snap.
Společnost Valve publikovala přehled To nej roku 2025 ve službě Steam aneb ohlédnutí za nejprodávanějšími, nejhranějšími a dalšími nej hrami roku 2025.
Byly publikovány výsledky průzkumu mezi uživateli Blenderu uskutečněného v říjnu a listopadu 2025. Zúčastnilo se více než 5000 uživatelů.
V dokumentově orientované databázi MongoDB byla nalezena a v upstreamu již opravena kritická bezpečností chyba CVE-2025-14847 aneb MongoBleed.
Při úklidu na Utažské univerzitě se ve skladovacích prostorách náhodou podařilo nalézt magnetickou pásku s kopií Unixu V4. Páska byla zaslána do počítačového muzea, kde se z pásky úspěšně podařilo extrahovat data a Unix spustit. Je to patrně jediný známý dochovaný exemplář tohoto 52 let starého Unixu, prvního vůbec programovaného v jazyce C.
FFmpeg nechal kvůli porušení autorských práv odstranit z GitHubu jeden z repozitářů patřících čínské technologické firmě Rockchip. Důvodem bylo porušení LGPL ze strany Rockchipu. Rockchip byl FFmpegem na porušování LGPL upozorněn již téměř před dvěma roky.
K dispozici je nový CLI nástroj witr sloužící k analýze běžících procesů. Název je zkratkou slov why-is-this-running, 'proč tohle běží'. Klade si za cíl v 'jediném, lidsky čitelném, výstupu vysvětlit odkud daný spuštěný proces pochází, jak byl spuštěn a jaký řetězec systémů je zodpovědný za to, že tento proces právě teď běží'. Witr je napsán v jazyce Go.
Yazi je správce souborů běžící v terminálu. Napsán je v programovacím jazyce Rust. Podporuje asynchronní I/O operace. Vydán byl v nové verzi 25.12.29. Instalovat jej lze také ze Snapcraftu.
Od soboty do úterý probíhá v Hamburku konference 39C3 (Chaos Communication Congress) věnovaná také počítačové bezpečnosti nebo hardwaru. Program (jiná verze) slibuje řadu zajímavých přednášek. Streamy a záznamy budou k dispozici na media.ccc.de.
Byl představen nový Xserver Phoenix, kompletně od nuly vyvíjený v programovacím jazyce Zig. Projekt Phoenix si klade za cíl být moderní alternativou k X.Org serveru.
-baseweb -web -snap20240513 -snap20240602 atd ...a moje představa je teď
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
-web
-snapshots
-web
-snap20240513
-snap20240613
Tedy data budou ve svých adresářích ( subvolumes ) a snapshoty v subvolume snapshots. Tuto změnu bych rád provedl v rámci jednoho disku, se zachováním dat a pokud možno i těch snapů. Možná je řešení triviální, ale btrfs důkladně neznám, tak se raději nejdříve zeptám vás.
Děkuji za nápomocné odpovědi ..
Řešení dotazu:
V rámci jednoho btrfs filesystému použij mv.
A co přesně to je, taková verze?
mv je v balíku zvaném coreutils, většinou. Obvyklá verze coreutils je momentálně 9.5.
Záleží na tom? (Proč?)
/dev/sda1 vytvořím btrfs (mkfs.btrfs /dev/sda1). Mountnu top-level subvolume filesystému (mount /dev/sda1 /mnt/t -o subvol=/). Vytvořím další subvolumy (btrfs subvolume create /mnt/t/{a,b,c}. Mountnu subvolume toho stejného filesystému (mount /dev/sda1 /mnt/a -o subvol=/a). Když teď přesunu subvolume pomocí mv, tak mv /mnt/t/b /mnt/t/a/ funguje, zatímco mv /mnt/t/c /mnt/a/ nefunguje. Resp. ono funguje oboje (ve smyslu, že to něco udělá a nehlásí to chybu), akorát to c už po přesunu není subvolume, ale je to adresář.
Mountnu subvolume toho stejného filesystému (mount /dev/sda1 /mnt/a -o subvol=/a).
Ano, souhlasím, že tenhle případ nefunguje správně. mv na jedné straně správě rozezná, že se jedná o stejný adresář / subvolume, a to i skrz explicitní mount point. Na druhé straně ale nerozezná možnost přesouvat skrz různé explicitní mount pointy efektivně. To je ošklivé.
Moje doporučení je nepoužívat explicitní mount pointy pro subvolume, pokud to jenom trochu jde. Znám případy, kdy to nejde: Když mám několik distribucí na jednom Btrfs a mám například subvolume /root_arch a /root_fedora a k nim /var/arch a /var/fedora (mountované dle potřeby jako / a /var). Nebo když nějaký backup systém na automatické snapshotování / verzování celého stromu používá různé dynamické názvy svých snapshotů, které automaticky vybírá a mountuje do známých názvů.
V takových situacích bohužel bude mv dělat brute-force kopie. (Na druhé straně: třeba mv mezi / a /var je podivný případ a všude možně jinde bych měl mít implicitní mount pointy (například mám-li ve svém /home pár subvolume, „mezi kterými“ (obrazně řečeno; v reálu nemají hierarchii) bych chtěl přesouvat jiné subvolume).)
Tady je názorně ten problém s brute-force kopií způsobenou explicitním mount pointem na subvolume:
btrfs subvolume create sub{1{,/{a,b}},2}
mkdir mnt{1,2}
{ IFS='[ ]' read -r device subvolume _; read -r mountpoint; } < <(
until findmnt -cfnoSOURCE -dbackward .; do cd ..; done
echo "$PWD")
mount -o subvol="${subvolume}${PWD#"${mountpoint}"}/sub1" "$device" mnt1
mount -o subvol="${subvolume}${PWD#"${mountpoint}"}/sub2" "$device" mnt2
mv sub1/a mnt1/ # mv: 'sub1/a' a 'mnt1/a' jsou jeden a tentýž soubor
mv sub1/a mnt2/ # OK <<< POZOR, brute-force kopie!
mv sub2/a sub1/ # OK <<< POZOR, brute-force kopie! (sub2/a je už jen adresář)
mv sub1/b sub2/ # OK <<< zachová subvolume
mv sub2/b sub1/ # OK <<< zachová subvolume
umount mnt{1,2}
rmdir mnt{1,2}
btrfs subvolume delete sub1/a # ERROR: Not a Btrfs subvolume: Invalid argument
btrfs subvolume delete sub{2,1{/b,}}
…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.
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,}
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 | 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 | vztah předek / zadek / potomek v copy-on-write hierarchii, částečně (v určitém smyslu) taky časovou osu, historii, kterou lze pomocí | ||
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 | 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 |
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“.
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.
Ten dotaz byl napsán nejednoznačně. Jak uvedl Andrej, v rámci jednoho FS nic zvláštního netřeba. Ovšem v rámci jednoho disku může být těch FS více, a všechny mohou být namountované do jedné adresářové struktury a pak pochopitelně příkaz mv bude mít úplně odlišný efekt.
Tiskni
Sdílej:
