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 15:18 | Zajímavý software

CrossOver, komerční produkt založený na Wine, je dnes (23. 5. 2017) dostupný ve slevě. Roční předplatné linuxové verze vyjde s kódem TWENTYONE na $21, resp. $1 v případě IP z chudších zemí jako ČR. Firma CodeWeavers, která CrossOver vyvíjí, významně přispívá do Wine. Přidaná hodnota CrossOver spočívá v přívětivějším uživatelském rozhraní, integraci do desktopu a podpoře.

Fluttershy, yay! | Komentářů: 10
dnes 15:11 | Zajímavý projekt

V únoru loňského roku bylo představeno několik útoků na celou řadu bezdrátových klávesnic a myší s názvem MouseJack. Po více než roce lze chybu opravit, tj. aktualizovat firmware, také z Linuxu. Richardu Hughesovi se podařilo navázat spolupráci se společností Logitech, získat od nich dokumentaci, přesvědčit je, aby firmware poskytovali přímo a ne jako součást .exe souboru, aby mohl být popis začleněn do služby Linux Vendor Firmware Service (LVFS) a aktualizace tak mohla proběhnou přímo z Linuxu pomocí projektu fwupd.

Ladislav Hagara | Komentářů: 0
dnes 13:22 | Nová verze

Po roce a půl vydali vývojáři projektu SANE (Scanner Access Now Easy) (Wikipedie) novou verzi 1.0.27 balíku SANE-Backends. Nejnovější verze tohoto balíku pro přístup ke skenerům přináší například významná vylepšení v několika backendech nebo podporu pro více než 30 nových modelů skenerů. Verze 1.0.26 byla přeskočena.

Ladislav Hagara | Komentářů: 0
včera 20:55 | Komunita

Od 18. do 21. května proběhla v Saint-Étienne Linux Audio Conference 2017. Na programu byla řada zajímavých přednášek a seminářů. Videozáznamy přednášek lze zhlédnout na YouTube. K dispozici jsou také články a prezentace.

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

Hodnota Bitcoinu, decentralizované kryptoměny, překonala hranici 2 200 dolarů. Za posledních 30 dnů tak vzrostla přibližně o 80 % [reddit].

Ladislav Hagara | Komentářů: 4
včera 17:33 | Nová verze

Po 5 měsících vývoje od vydání verze 0.12.0 byla vydána verze 0.13.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 83 vývojářů. Přibylo 840 nových balíčků. Jejich aktuální počet je 5 454. Aktualizována byla také dokumentace.

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

Po 5 měsících vývoje a 3 týdnech intenzivního testování byla vydána verze 12 open source systému Nextcloud, forku ownCloudu, umožňujícího provoz vlastního cloudového úložiště. Přehled novinek i s videoukázkami v poznámkách k vydání. Pro vyzkoušení je k dispozici demo.

Ladislav Hagara | Komentářů: 8
včera 11:44 | Zajímavý článek

Týden po prvním číslu publikoval Michal Špaček na svých stránkách druhé číslo newsletteru věnovanému bezpečnosti, bezpečnému vývoji převážně webových aplikací a bezpečnosti uživatelů. Věnuje se výpadku Let's Encrypt, únikům dat, bug bounty pro WordPress nebo SQL Injection v Joomla. Zmiňuje také, že Mozilla plánuje z Firefoxu odstranit podporu pro Encrypted Media Extensions (EME) na nešifrovaném HTTP a nadále pro EME vyžadovat HTTPS.

Ladislav Hagara | Komentářů: 0
včera 02:00 | Pozvánky

Ve středu 31. května 2017 od 17:00 proběhne v pražské pobočce SUSE Den otevřených dveří v SUSE. Čekají vás přednášky o live kernel patchingu a nástroji SaltStack. Také se dozvíte zajímavé informace o SUSE, openSUSE, a vlastně všech produktech, na kterých lidé ze SUSE pracují.

Ladislav Hagara | Komentářů: 4
včera 01:00 | Pozvánky

Czech JBoss User Group srdečně zve na setkání JBUG v Brně, které se koná ve středu 7. června 2017 v prostorách Fakulty informatiky Masarykovy univerzity v místnosti A318 od 18:00. Přednáší Tomáš Livora na téma Fault Tolerance with Hystrix. Více informací na Facebooku a Twitteru #jbugcz.

mjedlick | Komentářů: 0
Chystáte se pořídit CPU AMD Ryzen?
 (6%)
 (32%)
 (1%)
 (8%)
 (44%)
 (9%)
Celkem 597 hlasů
 Komentářů: 62, poslední 19.5. 01:57
    Rozcestník

    Dotaz: btrfs - divné datum po přejmenování subvolume / jak nejlépe smazat subvolume starší než ...?

    Pavel Čejka avatar 9.7.2014 15:30 Pavel Čejka | skóre: 28 | blog: tosinezaslouzijmeno
    btrfs - divné datum po přejmenování subvolume / jak nejlépe smazat subvolume starší než ...?
    Přečteno: 218×

    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.


    Řešení dotazu:


    Odpovědi

    Řešení 1× (Pavel Čejka (tazatel))
    Pavel Čejka avatar 10.7.2014 12:49 Pavel Čejka | skóre: 28 | blog: tosinezaslouzijmeno
    Rozbalit Rozbalit vše Re: btrfs - divné datum po přejmenování subvolume / jak nejlépe smazat subvolume starší než ...?

    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.

    15.7.2014 12:47 Jooky (inactive) | skóre: 39 | blog: Jooky | Bratislava
    Rozbalit Rozbalit vše Re: btrfs - divné datum po přejmenování subvolume / jak nejlépe smazat subvolume starší než ...?
    Vela ludi, co ovlada BTRFS asi nebude. Stale mam pocit, ze vela ludi pristupuje k btrfs s respektom ...

    Snapshot a subvolume je takmer to iste a samotny subvolume moze nahradit koren filesystem stromu. Preto ma vsetky vlastnosti ako kazdy iny directory vramci fs (m/c/a-time, prava, etc.). Pri snapshotovani snapshot zdedi vsetky tieto vlastnosti. Presne preto snapshoty vypadaju asi takto:
    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.

    btw. existuje aj lepsi sposob ako pouzivat "newermt" pre find. Find ma moznost "mtime" a "newer*" akceptuje aj textovy zapis

    Založit nové vláknoNahoru

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

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