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í
×
eParkomat, startup z ČR, postoupil mezi finalisty evropského akcelerátoru ChallengeUp!
Robot na pivo mu otevřel dveře k opravdovému byznysu
Internet věcí: Propojený svět? Už se to blíží...
dnes 11:44 | Zajímavý projekt

Na Indiegogo byla spuštěna kampaň na podporu herní mini konzole a multimediálního centra RetroEngine Sigma od Doyodo. Předobjednat ji lze již od 49 dolarů. Požadovaná částka 20 000 dolarů byla překonána již 6 krát. Majitelé mini konzole si budou moci zahrát hry pro Atari VCS 2600, Sega Genesis nebo NES. Předinstalováno bude multimediální centrum Kodi.

Ladislav Hagara | Komentářů: 0
dnes 00:10 | Nová verze

Byla vydána verze 4.7 redakčního systému WordPress. Kódové označením Vaughan bylo vybráno na počest americké jazzové zpěvačky Sarah "Sassy" Vaughan. Z novinek lze zmínit například novou výchozí šablonu Twenty Seventeen, náhledy pdf souborů nebo WordPress REST API.

Ladislav Hagara | Komentářů: 0
včera 12:00 | Zajímavý projekt

Projekt Termbox umožňuje vyzkoušet si linuxové distribuce Ubuntu, Debian, Fedora, CentOS a Arch Linux ve webovém prohlížeči. Řešení je postaveno na projektu HyperContainer. Podrobnosti v často kladených dotazech (FAQ). Zdrojové kódy jsou k dispozici na GitHubu [reddit].

Ladislav Hagara | Komentářů: 17
včera 11:00 | Bezpečnostní upozornění

Byly zveřejněny informace o bezpečnostní chybě CVE-2016-8655 v Linuxu zneužitelné k lokální eskalaci práv. Chyba se dostala do linuxového jádra v srpnu 2011. V upstreamu byla opravena minulý týden [Hacker News].

Ladislav Hagara | Komentářů: 2
5.12. 22:00 | Komunita

Přibližně před měsícem bylo oznámeno, že linuxová distribuce SUSE Linux Enterprise Server (SLES) běží nově také Raspberry Pi 3 (dokumentace). Obraz verze 12 SP2 pro Raspberry Pi 3 je ke stažení zdarma. Pro registrované jsou po dobu jednoho roku zdarma také aktualizace. Dnes bylo oznámeno, že pro Raspberry Pi 3 je k dispozici také nové openSUSE Leap 42.2 (zprávička). K dispozici je hned několik obrazů.

Ladislav Hagara | Komentářů: 6
5.12. 06:00 | Zajímavý software

OMG! Ubuntu! představuje emulátor terminálu Hyper (GitHub) postavený na webových technologiích (HTML, CSS a JavaScript). V diskusi k článku je zmíněn podobný emulátor terminálu Black Screen. Hyper i Black Screen používají framework Electron, stejně jako editor Atom nebo vývojové prostředí Visual Studio Code.

Ladislav Hagara | Komentářů: 50
5.12. 06:00 | Zajímavý článek

I letos vychází řada ajťáckých adventních kalendářů. QEMU Advent Calendar 2016 přináší každý den nový obraz disku pro QEMU. Programátoři se mohou potrápit při řešení úloh z kalendáře Advent of Code 2016. Kalendáře Perl Advent Calendar 2016 a Perl 6 Advent Calendar přinášejí každý den zajímavé informace o programovacím jazyce Perl. Stranou nezůstává ani programovací jazyk Go.

Ladislav Hagara | Komentářů: 10
3.12. 16:24 | Nová verze

Byla vydána Mageia 5.1. Jedná se o první opravné vydání verze 5, jež vyšla v červnu loňského roku (zprávička). Uživatelům verze 5 nepřináší opravné vydání nic nového, samozřejmě pokud pravidelně aktualizují. Vydání obsahuje všechny aktualizace za posledního téměř půldruhého roku. Mageia 5.1 obsahuje LibreOffice 4.4.7, Linux 4.4.32, KDE4 4.14.5 nebo GNOME 3.14.3.

Ladislav Hagara | Komentářů: 17
3.12. 13:42 | Pozvánky

V Praze probíhá konference Internet a Technologie 16.2, volné pokračování jarní konference sdružení CZ.NIC. Konferenci lze sledovat online na YouTube. K dispozici je také archiv předchozích konferencí.

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

Joinup informuje, že Mnichov používá open source groupware Kolab. V srpnu byl dokončen dvouletý přechod na toto řešení. V provozu je asi 60 000 poštovních schránek. Nejenom Kolabu se věnoval Georg Greve ve své přednášce Open Source: the future for the European institutions (SlideShare) na konferenci DIGITEC 2016, jež proběhla v úterý 29. listopadu v Bruselu. Videozáznam přednášek z hlavního sálu je ke zhlédnutí na Livestreamu.

Ladislav Hagara | Komentářů: 26
Kolik máte dat ve svém domovském adresáři na svém primárním osobním počítači?
 (32%)
 (24%)
 (29%)
 (8%)
 (5%)
 (3%)
Celkem 780 hlasů
 Komentářů: 50, poslední 29.11. 15:50
Rozcestník
Reklama

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: 201×

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 Lukáš Džunko | 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.