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 02:22 | Nová verze

    Společnost Murena představila (YouTube) novou verzi 4.0 mobilního operačního systému /e/OS (Wikipedie) založeného na Androidu a LineageOS bez aplikací a služeb od Googlu.

    Ladislav Hagara | Komentářů: 0
    včera 16:33 | Bezpečnostní upozornění

    V Arch User Repository (AUR) bylo kompromitováno přes 400 opomíjených balíčků (jejich seznam). Útočník do nich začlenil škodlivý npm balíček atomic-lockfile, který krade citlivá data uživatelů. Publikována byla předběžná analýza spouštěného malwaru deps.

    Ladislav Hagara | Komentářů: 8
    včera 11:33 | Nová verze

    Homebrew, správce balíčků nejen pro macOS, byl vydán ve verzi 6.0.0 (seznam změn). Hlavními novinkami jsou bezpečnostní mechanismus tap trust kvůli důvěryhodnosti závislostí, vylepšení sandboxingu na Linuxu, interní JSON API nebo zlepšení výkonu.

    |🇵🇸 | Komentářů: 0
    včera 03:33 | Bezpečnostní upozornění

    Byla nalezena a 9. června opravena kritická zranitelnost ve FreeBSD v Kernel TLS (KTLS). Pojmenována byla Bumsrakete (FreeBSD-SA-26:26.ktls, CVE-2026-45257). Lokální neprivilegovaný uživatel může přepisovat soubory, ke kterým má právo pouze pro čtení. Přepsáním setuid binárky a jejím spuštěním může získat roota. Na všech verzích od verze 13.0 vydané v dubnu 2021.

    Ladislav Hagara | Komentářů: 2
    11.6. 14:11 | Komunita

    Vývojáři open source operačního systému ReactOS (Wikipedie), jehož cílem je kompletní binární kompatibilita s aplikacemi a ovladači pro Windows, se na síti 𝕏 pochlubili, že ReactOS zvládne počítačovou hru Half-Life.

    Ladislav Hagara | Komentářů: 5
    11.6. 10:44 | Nová verze

    Byla vydána nová verze 4.8 multiplatformního integrovaného vývojového prostředí (IDE) pro rychlý vývoj aplikaci (RAD) ve Free Pascalu Lazarus (Wikipedie). Využíván je Free Pascal Compiler (FPC) 3.2.2.

    Ladislav Hagara | Komentářů: 0
    11.6. 04:44 | Nová verze

    Apple container dospěl do verze 1.0.0. Jedná se o open source nástroj pro spouštění linuxových kontejnerů na macOS postavený nad containerization. Napsaný je v programovacím jazyce Swift a optimalizovaný pro Apple silicon.

    Ladislav Hagara | Komentářů: 5
    11.6. 03:33 | Nová verze

    Bylo vydáno Eclipse IDE 2026-06 aneb Eclipse 4.40. Představení novinek tohoto integrovaného vývojového prostředí také na YouTube.

    Ladislav Hagara | Komentářů: 0
    10.6. 15:44 | Zajímavý software

    Asterinas (GitHub) je v Rustu napsané jádro operačního systému poskytující s jádrem Linux kompatibilní ABI. Vydána byla verze 0.18.0. První distribucí postavenou nad jádrem Asterinas je Asterinas NixOS. Nejedná se o oficiální projekt NixOS a nemá nic společného s NixOS Foundation.

    Ladislav Hagara | Komentářů: 2
    10.6. 13:22 | Zajímavý článek

    Podrobně byla rozebrána kritická zranitelnost v nf_tables (CVE-2026-23111). Další lokální eskalace práv na Linuxu. V upstreamu byla zranitelnost již v únoru opravena. Ve zdrojovém kódu stačilo odstranit 1 vykřičník.

    Ladislav Hagara | Komentářů: 1
    Které desktopové prostředí na Linuxu používáte?
     (11%)
     (8%)
     (2%)
     (16%)
     (31%)
     (3%)
     (6%)
     (3%)
     (15%)
     (26%)
    Celkem 1892 hlasů
     Komentářů: 30, poslední 3.4. 20:20
    Rozcestník


    Dotaz: ZFS snapshoty - kolik zabírají?

    16.3.2012 16:37 JanM | skóre: 28
    ZFS snapshoty - kolik zabírají?
    Přečteno: 393×
    Zdravím přítomné,

    tušíte někdo jak spočítat, kolik bajtů se uvolní při smazání konkrétního snapshotu na ZFS?
    # zfs snapshot srv/tracks@01
    # zfs list -t snapshot | grep tracks
    srv/tracks                                        29K   155G    29K  /srv/tracks
    srv/tracks@01                                       0      -    29K  -
    # dd if=/dev/zero of=/srv/tracks/file01 bs=1024 count=1000
    1000+0 records in
    1000+0 records out
    1024000 bytes (1.0 MB) copied, 0.0748983 s, 13.7 MB/s
    # snapshot srv/tracks@02
    # zfs list -t all | grep tracks
    srv/tracks                                      1.06M   155G  1.03M  /srv/tracks
    srv/tracks@01                                     26K      -    29K  -
    srv/tracks@02                                       0      -  1.03M  -
    # dd if=/dev/zero of=/srv/tracks/file02 bs=1024 count=1000
    1000+0 records in
    1000+0 records out
    1024000 bytes (1.0 MB) copied, 0.0730653 s, 14.0 MB/s
    # rm /srv/tracks/file01
    # zfs list -t all | grep tracks
    srv/tracks                                      2.08M   155G  2.03M  /srv/tracks
    srv/tracks@01                                     26K      -    29K  -
    srv/tracks@02                                     27K      -  1.03M  -
    # zfs snapshot srv/tracks@03
    # zfs list -t all | grep tracks
    srv/tracks                                      2.09M   155G  1.03M  /srv/tracks
    srv/tracks@01                                     26K      -    29K  -
    srv/tracks@02                                   1.03M      -  1.03M  -
    srv/tracks@03                                       0      -  1.03M  -
    
    Až potud celkem fajn, dataset srv/tracks zabírá 2.09 MB, což obsahuje file01 v @02 a file02 v @03. Aktuální velikost datasetu je 1.03 MB, neb file01 byl již smazán.
    # zfs destroy srv/tracks@02
    # zfs list -t all | grep tracks
    srv/tracks                                      1.06M   155G  1.03M  /srv/tracks
    srv/tracks@01                                     27K      -    29K  -
    srv/tracks@03                                       0      -  1.03M  -
    # zfs snapshot srv/tracks@04
    # zfs list -t all | grep tracks
    srv/tracks                                      1.06M   155G  1.03M  /srv/tracks
    srv/tracks@01                                     27K      -    29K  -
    srv/tracks@03                                       0      -  1.03M  -
    srv/tracks@04                                       0      -  1.03M  -
    # zfs snapshot srv/tracks@05
    # zfs list -t all | grep tracks
    srv/tracks                                      1.06M   155G  1.03M  /srv/tracks
    srv/tracks@01                                     27K      -    29K  -
    srv/tracks@03                                       0      -  1.03M  -
    srv/tracks@04                                       0      -  1.03M  -
    srv/tracks@05                                       0      -  1.03M  -
    
    Pokud nyní odstraním snapshoty @03, @04 a @05, nic neušetřím, neb soubor file02 stále existuje v srv/tracks.
    # rm /srv/tracks/file02
    # zfs list -t all | grep tracks
    srv/tracks                                      1.06M   155G  1.03M  /srv/tracks
    srv/tracks@01                                     27K      -    29K  -
    srv/tracks@03                                       0      -  1.03M  -
    srv/tracks@04                                       0      -  1.03M  -
    srv/tracks@05                                       0      -  1.03M  -
    
    Pokud nyní odstraním snapshoty @03, @04 a @05, ušetřím 1.03 MB prostoru. Jak to ale zjistit z výpisu zfs list -t snapshot, když i v předchozím kroku zobrazil stejné informace?
    # for i in 03 04 05; do zfs destroy srv/tracks@$i; done
    # zfs list -t all | grep tracks
    srv/tracks                                        56K   155G    29K  /srv/tracks
    srv/tracks@01                                     27K      -    29K  -
    
    Ať se dívám, jak se dívám, spolehlivě se nedá vyčíst, kolik místa ušetřím smazáním nějakého snapshotu.

    Nebo někdo zná nějaký fígl?

    Odpovědi

    blami avatar 17.3.2012 02:49 blami | skóre: 29 | Praha
    Rozbalit Rozbalit vše Re: ZFS snapshoty - kolik zabírají?
    Nesedim ted u Solarisu a tudiz varim z vody, ale zkusil bych zfs list -t all -o size. Z toho vypisu by to melo jit vycist.
    19.3.2012 20:31 JanM | skóre: 28
    Rozbalit Rozbalit vše Re: ZFS snapshoty - kolik zabírají?
    Hm, nevím, hledal jsem hledal, ale buď špatně anebo to není možné.

    Existuje "used" a "refer", přičemž ta první se odkazuje na velikost dat skutečně alokovanou konkrétnímu snapshotu, ta druhá vlastnost popisuje velikost souborového systému v okamžiku vytvoření snapshotu.

    Takže "used" by měla být to pravé, nicméně to nefunguje v případě, kdy jsou data obsažena ve dvou snapshotech (celkem logicky), ale v aktuálním souborovém systému již chybí. V takovém případě je "used" stále nulové. Stačí však smazat jeden snapshot a náhle se "used" toho zbývajícího rovná velikosti již smazaných dat.

    Chtělo by to nějakou utilitku, která by zvládla spočítat a hlavně nějak prezentovat, kolik dat by se dalo ušetřit promazáním některých snapshotů.

    Tzn., že by musela zjistit, která data již neexistují v souborovém systému a kterými snapshoty jsou sdílena. Pak to seřadit dle velikosti a/nebo počtu sdílejících snapshotů.

    Možná by se dal využít "zfs diff", nicméně ten zatím pro ZFS on Linux nebyl implementován.

    P.S. Řeším to proto, že při zaplnění záložního disku se mi nezdá nejlepší varianta mazat automaticky nejstarší snapshoty, ale spíše identifikovat ty objemné, a buď tyto smazat, anebo naklonovat a smazat jen příslušné soubory a znovu rsyncem vytvořit i snapshoty následné, avšak bez inkriminovaných souborů. Trochu overkill.

    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.