Mezinárodní federace hudebního průmyslu (International Federation of the Phonographic Industry) navrhla Evropské komisi zařazení populárního open-source nástroje yt-dlp na evropský seznam 'padělků a pirátství' (EU Counterfeit and Piracy Watch List) pro rok 2027 (plné znění žádosti IFPI). IFPI ve svém podání označuje tento aktivně vyvíjený a o rozličné funkce bohatší fork youtube-dl za 'závažný problém' pro hudební průmysl, v
… více »Byla vydána nová verze 7.4 linuxové distribuce Parrot OS (Wikipedie). Jedná se o linuxovou distribuci založenou na Debianu a zaměřenou na penetrační testování, digitální forenzní analýzu, reverzní inženýrství, hacking, anonymitu nebo kryptografii. Přehled novinek v příspěvku na blogu.
Dnes startuje desátý ročník oblíbené kyberbezpečnostní soutěže The Catch organizované Forenzní laboratoří CESNETu. Letos zavede soutěžící do světa národních výzkumných a vzdělávacích sítí (NREN). Čekají na vás tematické úlohy založené na principu Capture the Flag (CTF), hledání ukrytých flagů i zajímavé ceny. Otestujte své schopnosti a vyrazte na lov flagů.
Byly zpracovány a na YouTube zveřejněny videozáznamy z konference LinuxDays 2026.
Německý startup Aleph Alpha k příležitosti výročí sjednocení Německa zveřejnil open-weight jazykový model Kolibri, vyvíjený s ohledem na unijní pojetí autorského práva, ochranu osobních údajů GDPR a nařízení EU o umělé inteligenci, jehož 'Kodexu správné praxe' je Aleph Alpha signatářem. Výsledkem tohoto přístupu je transparentnější technologie, kterou například budou moci využívat evropské veřejné instituce, ovšem za cenu
… více »Nvidia zveřejnila návrh nové bezpečnostní platformy pro nasazování AI agentů. Jedná se o nasazení AI za použití OpenShell a Sentry, dvou oddělených bezpečnostních vrstev, v nichž může Sentry monitorovat a vyhodnocovat chování AI v OpenShellu tak, že ho v krajním případě až vypne. Mělo by to zabránit dalším únikům AI ze sandboxu.
Přímý přenos (YouTube) z konference LinuxDays 2026, jež probíhá tento víkend v Praze v prostorách FIT ČVUT. Na programu je spousta zajímavých přednášek.
Byla vydána nová verze 0.17.0 programovacího jazyka Zig (Codeberg, Wikipedie). Přispělo 206 vývojářů. Přehled novinek v poznámkách k vydání.
Open-source projekt OpenDLSS-NR je 'bitově přesná reimplementace' neuronové rendrovací sítě DLSS 5 od společnosti NVIDIA, jenže pro grafické API Vulkan (DLSS slouží k vylepšování klasickým způsobem vyrendrovaných snímků pomocí lokálních modelů umělé inteligence, a to v reálném čase). Projekt není nijak spojen se společností NVIDIA, je pouze pro OS Windows a natrénované váhy modelu si uživatelé musí obstarat sami. Zdrojový kód je k dispozici na GitHubu, pod licencí MIT s výjimkou pro komponenty třetích stran.
Společnost Cloudflare představila Clef a Clef-Flash, open-source rozhodovací modely určené pro rychlou a konzistentní klasifikaci vstupů. Na rozdíl od klasických LLM vracejí tyto modely deterministické striktně typované strukturované odpovědi s exaktními pravděpodobnostmi, tedy odpovědi ve stylu přelomového modelu Jev.
… více »
9.7.2014 15:30
Pavel Čejka | skóre: 28
| blog: tosinezaslouzijmeno
Trochu si hraju se zálohováním (na nedůležité kopii) a přihodila se mi zajímavá věc.
Přejmenoval jsem všechny subvolume pomocí mc (přidal jsem do názvu slovo snapshot) a změnily se u nich data poslední modifikace a ještě ke všemu na jiné datum, než systémové, které ukazuje date. Přičemž do obsahu subvolume jsem nijak nezasahoval a datum změny složky ve výpisu subvolumes je taky odlišné (shodné s tím v názvu, které odpovídá skutečnosti).
aktuální datum na použitém stroji
koprolit backup_btrfs # date St čec 9 13:45:16 CEST 2014
zatímco datum složek na btrfs
koprolit __skripty_devel # ls /mnt/backup_btrfs/ -l celkem 4 drwxr-xr-x 1 root root 60 2. čec 11.25 balast drwxr-xr-x 1 root root 12 25. čen 17.53 daily_rsync_subvolume drwxr-xr-x 1 root root 12 25. čen 17.53 daily_rsync_subvolume_snapshot_2014-06-26-151657 drwxr-xr-x 1 root root 12 25. čen 17.53 daily_rsync_subvolume_snapshot_2014-06-26-152314 drwxr-xr-x 1 root root 12 25. čen 17.53 daily_rsync_subvolume_snapshot_2014-06-26-152439 drwxr-xr-x 1 root root 12 25. čen 17.53 daily_rsync_subvolume_snapshot_2014-06-26-152528 drwxr-xr-x 1 root root 12 25. čen 17.53 daily_rsync_subvolume_snapshot_2014-06-26-152608 drwxr-xr-x 1 root root 12 25. čen 17.53 daily_rsync_subvolume_snapshot_2014-06-26-152639 drwxr-xr-x 1 root root 12 25. čen 17.53 daily_rsync_subvolume_snapshot_2014-06-26-152710 drwxr-xr-x 1 root root 12 25. čen 17.53 daily_rsync_subvolume_snapshot_2014-06-27-151114 drwxr-xr-x 1 root root 12 25. čen 17.53 daily_rsync_subvolume_snapshot_2014-06-30-164616 drwxr-xr-x 1 root root 12 25. čen 17.53 daily_rsync_subvolume_snapshot_2014-07-02-112312 drwxr-xr-x 1 root root 12 25. čen 17.53 daily_rsync_subvolume_snapshot_2014-07-02-153708 drwxr-xr-x 1 root root 12 25. čen 17.53 daily_rsync_subvolume_snapshot_2014-07-02-164811 drwxr-xr-x 1 root root 12 25. čen 17.53 daily_rsync_subvolume_snapshot_2014-07-02-182647 drwxr-xr-x 1 root root 12 25. čen 17.53 daily_rsync_subvolume_snapshot_2014-07-03-101315 drwxr-xr-x 1 root root 12 25. čen 17.53 daily_rsync_subvolume_snapshot_2014-07-03-141125 drwxr-xr-x 1 root root 12 25. čen 17.53 daily_rsync_subvolume_snapshot_2014-07-03-141134 drwxr-xr-x 1 root root 12 25. čen 17.53 daily_rsync_subvolume_snapshot_2014-07-08-161924 drwxr-xr-x 1 root root 12 25. čen 17.53 daily_rsync_subvolume_snapshot_2014-07-09-114911 drwxr-xr-x 1 root root 12 25. čen 17.53 daily_rsync_subvolume_snapshot_2014-07-09-121846 drwxr-xr-x 1 root root 12 25. čen 17.53 daily_rsync_subvolume_snapshot_2014-07-09-134950 -rw-r--r-- 1 root root 79 25. čen 17.24 2G zabira samotne BTRFS
Domníval jsem se, že by datum 25.6. mohlo odpovídat datu vytvoření filesystému, ale spíš ne. Podle messages to bylo o 2 dny dřív.
Jun 23 15:10:54 koprolit kernel: BTRFS: device fsid 2380d3b6-a5e0-45d2-8707-06faae2bbce8 devid 1 transid 4 /dev/sdg1 Jun 23 15:10:54 koprolit kernel: BTRFS info (device sdg1): disk space caching is enabled Jun 23 15:10:54 koprolit kernel: BTRFS: flagging fs with big metadata feature Jun 23 15:10:57 koprolit kernel: BTRFS: creating UUID tree
datum složky ve všech subvolume (obsah složky servis se následně mírně liší)
drwx------ 1 servis 1013 14 30. říj 2010 servis
otime ve výpisu subvolumes jsou správně
koprolit daily_rsync_subvolume_snapshot_2014-07-03-141125 # btrfs subvolume list -s --sort=gen /mnt/backup_btrfs/ ID 262 gen 149 cgen 75 top level 5 otime 2014-06-26 15:16:58 path daily_rsync_subvolume_snapshot_2014-06-26-151657 ID 263 gen 149 cgen 78 top level 5 otime 2014-06-26 15:23:14 path daily_rsync_subvolume_snapshot_2014-06-26-152314 ID 264 gen 149 cgen 80 top level 5 otime 2014-06-26 15:24:39 path daily_rsync_subvolume_snapshot_2014-06-26-152439 ID 265 gen 149 cgen 82 top level 5 otime 2014-06-26 15:25:28 path daily_rsync_subvolume_snapshot_2014-06-26-152528 ID 266 gen 149 cgen 84 top level 5 otime 2014-06-26 15:26:08 path daily_rsync_subvolume_snapshot_2014-06-26-152608 ID 267 gen 149 cgen 86 top level 5 otime 2014-06-26 15:26:39 path daily_rsync_subvolume_snapshot_2014-06-26-152639 ID 268 gen 149 cgen 88 top level 5 otime 2014-06-26 15:27:10 path daily_rsync_subvolume_snapshot_2014-06-26-152710 ID 269 gen 149 cgen 90 top level 5 otime 2014-06-27 15:11:14 path daily_rsync_subvolume_snapshot_2014-06-27-151114 ID 270 gen 149 cgen 108 top level 5 otime 2014-06-30 16:46:22 path daily_rsync_subvolume_snapshot_2014-06-30-164616 ID 271 gen 149 cgen 110 top level 5 otime 2014-07-02 11:23:13 path daily_rsync_subvolume_snapshot_2014-07-02-112312 ID 272 gen 149 cgen 122 top level 5 otime 2014-07-02 15:37:11 path daily_rsync_subvolume_snapshot_2014-07-02-153708 ID 273 gen 149 cgen 124 top level 5 otime 2014-07-02 16:48:15 path daily_rsync_subvolume_snapshot_2014-07-02-164811 ID 274 gen 149 cgen 126 top level 5 otime 2014-07-02 18:26:47 path daily_rsync_subvolume_snapshot_2014-07-02-182647 ID 275 gen 149 cgen 128 top level 5 otime 2014-07-03 10:13:24 path daily_rsync_subvolume_snapshot_2014-07-03-101315 ID 276 gen 149 cgen 130 top level 5 otime 2014-07-03 14:11:25 path daily_rsync_subvolume_snapshot_2014-07-03-141125 ID 277 gen 149 cgen 132 top level 5 otime 2014-07-03 14:11:34 path daily_rsync_subvolume_snapshot_2014-07-03-141134 ID 278 gen 149 cgen 135 top level 5 otime 2014-07-08 16:20:42 path daily_rsync_subvolume_snapshot_2014-07-08-161924 ID 279 gen 149 cgen 138 top level 5 otime 2014-07-09 11:50:29 path daily_rsync_subvolume_snapshot_2014-07-09-114911 ID 280 gen 149 cgen 140 top level 5 otime 2014-07-09 12:18:47 path daily_rsync_subvolume_snapshot_2014-07-09-121846 ID 281 gen 150 cgen 150 top level 5 otime 2014-07-09 13:49:50 path daily_rsync_subvolume_snapshot_2014-07-09-134950
jádro
Linux version 3.14.5 (root@koprolit) (gcc version 4.6.3 (Gentoo 4.6.3 p1.13, pie-0.5.2) ) #1 SMP Fri Jun 6 13:48:39 CEST 2014
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.czkoprolit backup_btrfs # btrfs filesystem show -d
Label: none uuid: 2380d3b6-a5e0-45d2-8707-06faae2bbce8
Total devices 1 FS bytes used 926.70MiB
devid 1 size 14.91GiB used 1.31GiB path /dev/sdg1
Btrfs v3.12
koprolit backup_btrfs # btrfs filesystem df /mnt/backup_btrfs/
Data, single: total=1.00GiB, used=917.65MiB
System, DUP: total=32.00MiB, used=16.00KiB
Metadata, DUP: total=128.00MiB, used=9.03MiB
Rád bych nějakým spolehlivým způsobem odstraňoval subvolumes starší než zadaný počet dní, o což jsem se pokoušel např. find /mnt/backup_btrfs -maxdepth 1 ! -newermt $(date --date='3 weeks ago' +%Y-%m-%d) -type d a ono by to i fungovalo, kdyby se nepokazily časy.
Otázkou je - je to bug? featura? stalo se vám to jinde? Je to už opravené?
Zkusil jsem touch -d nějaké_datum na daily_rsync_subvolume, ze kterého se dělají snapshoty a nově vytvořený snapshot bude mít toto datum. Je to správné chování?. Jsem si jistý, že to tak nebylo a že předtím měly subvolumes datum shodné s tím, co mají v názvu, tj. odpovídající otime - času vytvoření.
Koukám do stat na atime a mtime, namátkou ...
Soubor: „daily_rsync_subvolume_snapshot_2014-07-09-150355“
Velikost: 12 Bloků: 0 I/O blok: 4096 adresář
Zařízení: 36h/54d I-uzel: 256 Odkazů: 1
Práva: (0755/drwxr-xr-x) UID: ( 0/ root) GID: ( 0/ root)
Přístup: 2014-07-09 14:56:22.084460333 +0200
Změna obsahu: 2014-07-09 14:56:15.064460489 +0200
Změna i-uzlu: 2014-07-09 14:56:15.064460489 +0200
Vznik: -
Soubor: „daily_rsync_subvolume_snapshot_2014-07-09-150512“
Velikost: 12 Bloků: 0 I/O blok: 4096 adresář
Zařízení: 37h/55d I-uzel: 256 Odkazů: 1
Práva: (0755/drwxr-xr-x) UID: ( 0/ root) GID: ( 0/ root)
Přístup: 2014-07-09 14:56:22.084460333 +0200
Změna obsahu: 2014-07-09 14:56:15.064460489 +0200
Změna i-uzlu: 2014-07-09 14:56:15.064460489 +0200
Vznik: -
Soubor: „daily_rsync_subvolume_snapshot_2014-07-09-150621“
Velikost: 12 Bloků: 0 I/O blok: 4096 adresář
Zařízení: 38h/56d I-uzel: 256 Odkazů: 1
Práva: (0755/drwxr-xr-x) UID: ( 0/ root) GID: ( 0/ root)
Přístup: 2014-07-09 14:56:22.084460333 +0200
Změna obsahu: 2014-07-09 14:56:15.064460489 +0200
Změna i-uzlu: 2014-07-09 14:56:15.064460489 +0200
Vznik: -
A taky mne zajímá, jestli neexistuje lepší/spolehlivější způsob, jak vytřídit staré subvolumes. Ideální by bylo něco podobného parametru -newermt u find aplikované na otime ve výpisu subvolumes směrovatelné přes xargs na btrfs subvolume delete. Na disku jiné subvolumes nebudou ... bude tam nanejvýš nějaká normální složka s ruční zálohou, nebo pár souborů se servisními informacemi mimo subvolumes.
Řešení dotazu:
10.7.2014 12:49
Pavel Čejka | skóre: 28
| blog: tosinezaslouzijmeno
Jak se zdá, chyba je asi opět na židli... odpovím si sám, lidí používajících btrfs zde zřejmě moc není.
Fakt jsem si byl skoro jistý, že data snapshotů odpovídají času vytvoření, ale není to pravda. Data snapshotů se kopírují z mtime subvolume ze kterého byly vytvořeny.
Poučení - při experimentování logovat i to, co by mne nenapadlo logovat. A že toho i teď mám v logu svého skriptu dost, ale zrovna tohle ne. A s findem jsem si začal na btrfs hrát až včera.
Ověřil jsem si krom druhého disku i zde http://marc.merlins.org/perso/btrfs/2014-03.html. Konkrétně tento výpis:
drwxr-xr-x 1 root root 370 Feb 24 10:38 root drwxr-xr-x 1 root root 370 Feb 24 10:38 root_daily_20140316_00:05:01 drwxr-xr-x 1 root root 370 Feb 24 10:38 root_daily_20140318_00:05:01 drwxr-xr-x 1 root root 370 Feb 24 10:38 root_daily_20140319_00:05:01 drwxr-xr-x 1 root root 370 Feb 24 10:38 root_daily_20140320_00:05:00 drwxr-xr-x 1 root root 370 Feb 24 10:38 root_hourly_20140316_22:33:00 drwxr-xr-x 1 root root 370 Feb 24 10:38 root_hourly_20140318_00:05:01 drwxr-xr-x 1 root root 370 Feb 24 10:38 root_hourly_20140319_00:05:01 drwxr-xr-x 1 root root 370 Feb 24 10:38 root_hourly_20140320_00:05:00 drwxr-xr-x 1 root root 336 Feb 19 21:40 root_weekly_20140223_00:06:01 drwxr-xr-x 1 root root 370 Feb 24 10:38 root_weekly_20140302_00:06:01 drwxr-xr-x 1 root root 370 Feb 24 10:38 root_weekly_20140309_00:06:01 drwxr-xr-x 1 root root 370 Feb 24 10:38 root_weekly_20140316_00:06:01
Kde je zcela jasně vidět, že mtime snapshotů je shodné s mtime subvolume root.
Řešení při záloze je jednoduché - touch na subvolume do kterého se rsyncuje těsně před vytvořením snapshotu.
Náprava chyby taky není složitá.
#!/bin/bash
DIR="/mnt/backup_btrfs"
LIST=$(ls $DIR -1 | grep snapshot)
for SUBDIR in $LIST; do
DATUM=$(btrfs subvolume list -s $DIR | grep "$SUBDIR" |cut -d " " -f 11,12)
echo $DIR/$SUBDIR" "$DATUM
touch -d "$DATUM" $DIR/$SUBDIR
done
Čas pak odpovídá času dokončení zálohy. Tj. liší se od času v názvu o dobu běhu rsyncu.
phoebe backup # ls -l total 0 drwxr-xr-x 1 root root 146 Feb 8 03:17 phoebe drwxr-xr-x 1 root root 146 Feb 8 03:17 phoebe_2014-05-30_1401485335 drwxr-xr-x 1 root root 146 Feb 8 03:17 phoebe_2014-06-26_1403778630 drwxr-xr-x 1 root root 146 Feb 8 03:17 phoebe_2014-07-01_1404201463 drwxr-xr-x 1 root root 146 Feb 8 03:17 phoebe_2014-07-08_1404821255 drwxr-xr-x 1 root root 146 Feb 8 03:17 phoebe_2014-07-09_1404942949 drwxr-xr-x 1 root root 146 Feb 8 03:17 phoebe_2014-07-15_1405420366 phoebe backup #Jedna moznost je spravit touch a druha poriet creation time na subvolume:
phoebe backup # for a in *; do btrfs sub show ${a} | grep -e /mnt -e Creation; echo; done
/mnt/backup/phoebe
Creation time: 2014-02-21 20:06:17
/mnt/backup/phoebe_2014-05-30_1401485335
Creation time: 2014-05-30 23:28:56
/mnt/backup/phoebe_2014-06-26_1403778630
Creation time: 2014-06-26 12:30:30
/mnt/backup/phoebe_2014-07-01_1404201463
Creation time: 2014-07-01 09:57:43
/mnt/backup/phoebe_2014-07-08_1404821255
Creation time: 2014-07-08 14:07:35
/mnt/backup/phoebe_2014-07-09_1404942949
Creation time: 2014-07-09 23:55:49
/mnt/backup/phoebe_2014-07-15_1405420366
Creation time: 2014-07-15 12:32:46
phoebe backup #
Ja preferujem znacky v nazve snapshotu. Podla toho sa rozhodujem ci snapshot zmazat, alebo nie.
Tiskni
Sdílej:
