abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
Přihlášení | Registrace
×
napište » Zprávičky
inzerujte » Pracovní nabídky
    VASA-1, generování mluvící hlavy z jediné fotky a zvukového záznamu
    dnes 14:22 | IT novinky

    VASA-1, výzkumný projekt Microsoftu. Na vstupu stačí jediná fotka a zvukový záznam. Na výstupu je dokonalá mluvící nebo zpívající hlava. Prý si technologii nechá jenom pro sebe. Žádné demo, API nebo placená služba. Zatím.

    Ladislav Hagara | Komentářů: 0
    MagPi 140 a HackSpace 77
    dnes 04:44 | Nová verze

    Nová čísla časopisů od nakladatelství Raspberry Pi: MagPi 140 (pdf) a HackSpace 77 (pdf).

    Ladislav Hagara | Komentářů: 0
    ESPHome 2024.4.0
    dnes 01:00 | Nová verze

    ESPHome, tj. open source systém umožňující nastavovat zařízení s čipy ESP (i dalšími) pomocí konfiguračních souborů a připojit je do domácí automatizace, například do Home Assistantu, byl vydán ve verzi 2024.4.0.

    Ladislav Hagara | Komentářů: 0
    Open Platform for Enterprise AI (OPEA)
    včera 22:11 | IT novinky

    LF AI & Data Foundation patřící pod Linux Foundation spustila Open Platform for Enterprise AI (OPEA).

    Ladislav Hagara | Komentářů: 0
    OpenXR 1.1
    včera 20:55 | Nová verze

    Neziskové průmyslové konsorcium Khronos Group vydalo verzi 1.1 specifikace OpenXR (Wikipedie), tj. standardu specifikujícího přístup k platformám a zařízením pro XR, tj. platformám a zařízením pro AR (rozšířenou realitu) a VR (virtuální realitu). Do základu se z rozšíření dostalo XR_EXT_local_floor. Společnost Collabora implementuje novou verzi specifikace do platformy Monado, tj. open source implementace OpenXR.

    Ladislav Hagara | Komentářů: 2
    mpv 0.38.0
    včera 17:22 | Nová verze

    Byla vydána nová verze 0.38.0 multimediálního přehrávače mpv (Wikipedie) vycházejícího z přehrávačů MPlayer a mplayer2. Přehled novinek, změn a oprav na GitHubu. Požadován je FFmpeg 4.4 nebo novější a také libplacebo 6.338.2 nebo novější.

    Ladislav Hagara | Komentářů: 13
    ClamAV 1.3.1, 1.2.3 a 1.0.6
    včera 17:11 | Nová verze

    ClamAV (Wikipedie), tj. multiplatformní antivirový engine s otevřeným zdrojovým kódem pro detekci trojských koní, virů, malwaru a dalších škodlivých hrozeb, byl vydán ve verzích 1.3.1, 1.2.3 a 1.0.6. Ve verzi 1.3.1 je mimo jiné řešena bezpečnostní chyba CVE-2024-20380.

    Ladislav Hagara | Komentářů: 2
    Mobilní aplikace Portál občana je ode dneška oficiálně venku
    včera 12:11 | IT novinky

    Digitální a informační agentura (DIA) oznámila (PDF, X a Facebook), že mobilní aplikace Portál občana je ode dneška oficiálně venku.

    Ladislav Hagara | Komentářů: 10
    #HACKUJBRNO 2024
    včera 05:11 | Komunita

    #HACKUJBRNO 2024, byly zveřejněny výsledky a výstupy hackathonu města Brna nad otevřenými městskými daty, který se konal 13. a 14. dubna 2024.

    Ladislav Hagara | Komentářů: 2
    Volla Tablet na Kickstarteru
    17.4. 17:55 | IT novinky

    Společnost Volla Systeme stojící za telefony Volla spustila na Kickstarteru kampaň na podporu tabletu Volla Tablet s Volla OS nebo Ubuntu Touch.

    Ladislav Hagara | Komentářů: 3
    Centrum | Napsat | Starší
    navrhněte » Anketa
    KDE Plasma 6
     (68%)
     (10%)
     (2%)
     (20%)
    Celkem 563 hlasů
     Komentářů: 4, poslední 6.4. 15:51
    Rozcestník
    AbcLinuxu
    HDmag.cz

    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
    9.7.2014 15:30 Pavel Čejka | skóre: 28 | blog: tosinezaslouzijmeno
    Rozbalit Rozbalit vše btrfs - divné datum po přejmenování subvolume / jak nejlépe smazat subvolume starší než ...?

    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
    koprolit 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.

    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
    Píšeme jinde
    ISSN 1214-1267   www.czech-server.cz
    Redakce | Inzerce | Podmínky použití | Osobní údaje
    © 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.