Společnost Red Hat představila program "Red Hat Enterprise Linux (RHEL) for Open Source Infrastructure" aneb Red Hat Enterprise Linux zdarma pro open source projekty.
Spolek OpenAlt zve příznivce otevřených řešení a přístupu na 190. sraz, který proběhne v pátek 26. února od 17:00 na Jitsi Meet.
Po open source ergonomickému trackballu (dnes Classic Trackball) a open source myši představila společnost Ploopy nový open source Nano Trackball (GitHub). Trackball bez tlačítek a kolečka. Pouze kulička.
Webový prohlížeč Brave lze vedle standardního prohlížení (Nové okno) a anonymního prohlížení (Nové soukromé okno) používat i pro anonymní prohlížení s využitím Toru (Nové soukromé okno přes Tor) a pro přistup k webům v doméně .onion. Nejnovější verze Brave řeší několik bezpečnostních chyb, kdy DNS dotazy místo do Toru směrovaly k poskytovateli DNS. Ten tak mohl zjistit, že uživatel chtěl přistupovat například k sejnfjrq6szgca7v.onion (debian.org).
Byla vydána nová verze 2021.1 průběžně aktualizované linuxové distribuce navržené pro digitální forenzní analýzu a penetrační testování Kali Linux (Wikipedie). Přehled novinek i s náhledy a seznamem nových nástrojů v oficiálním oznámení. Kali Linux má nové webové stránky.
Multiplatformní open source počítačová hra Minetest byla vydána ve verzi 5.4.0. Přehled změn v changelogu. Jedná se o hru inspirovanou Minecraftem.
Byla vydána (Twitter) nová verze 3.18 svobodného multiplatformního geografického informačního systému QGIS (Wikipedie). Přehled novinek i s náhledy a animovanými gify ve visuálním changelogu a také na YouTube.
Byla vydána nová verze 4.16 živé linuxové distribuce Tails (The Amnesic Incognito Live System), jež klade důraz na ochranu soukromí uživatelů a anonymitu. Přehled změn v příslušném seznamu. Tor Browser byl aktualizován na verzi 10.0.12. Thunderbird byl aktualizován na verzi 78.7.0. Linux byl aktualizován na verzi 5.10.13. Tor byl aktualizován na verzi 0.4.5.5.
Dokumentační tým projektu LibreOffice vydává příručku Getting Started Guide 7.0. Příručka je určena pro každého, kdo se chce seznámit s programem LibreOffice a představuje hlavní komponenty LibreOffice: textový procesor Writer, tabulkový procesor Calc, prezentační program Impress, vektorový grafický program Draw, databázový program Base a editor rovnic Math. Příručka je ke stažení na stránce LibreOffice, kde lze stáhnout i české překlady dalších příruček.
Byl vydán Mozilla Firefox 86.0. Přehled novinek v poznámkách k vydání, poznámkách k vydání pro firmy a na stránce věnované vývojářům. Novinkou je Total Cookie Protection aneb "každý web má vlastní dózu na sušenky". Nově lze používat funkci obraz v obraze současně pro několik videí. Řešeny jsou také bezpečnostní chyby. Nejnovější Firefox je již k dispozici také na Flathubu.
Label: 'archiv' uuid: d1722103-0c1e-4627-bbc7-9f1f0bf91739 Total devices 4 FS bytes used 4.56TiB devid 1 size 3.64TiB used 3.30TiB path /dev/mapper/archiv devid 2 size 3.64TiB used 3.30TiB path /dev/mapper/com devid 3 size 1.36TiB used 1.03TiB path /dev/mapper/miraza devid 4 size 1.82TiB used 1.49TiB path /dev/mapper/securestoragecíl: extení disk USB 3.0 připojený jako
sdo
má ntfs filesystem. Kopírování rsync -av zdroj cíl
To co mne zaráží je mrňavé požadavky na IOPS pro zápis na ntfs a naopak obrovské IOPS, které se koncentrují do disku com
. Soubor throughput ukazuje, že co se přečte, to se zapíše. mount btrfs je/dev/mapper/archiv /disky/archiv btrfs commit=100,defaults 0 0(v mount je
type btrfs (rw,relatime,space_cache,commit=100,subvolid=5,subvol=/)
) a ntfs je standardní automount(v mount je type fuseblk (rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096,uhelper=udisks2)
) Případně jak pole mountnout aby výkon byl větší (každý /dev/mapper toho pole je LUKS2 volume)
Naopak kdybys mel btrfs na obou stranachPokud je to záloha, tak je dobré mít pro zálohu jiný FS než na zálohovaném systému. Kdyby byl bug v kernel modulu daného FS, který by ten FS zničil, tak ti to zničí jak originální FS tak i zálohu. Takže jiný FS je zde na místě. (Otázkou je proč zrovna NTFS přes fuse...)
To co mne zaráží je mrňavé požadavky na IOPS pro zápis na ntfs a naopak obrovské IOPSAno, tohle je docela běžné, protože pro zápis se používá mnoho technik pro odložený zápis, aby si to FS mohl srovnat v paměti a zapsat to co nejefektivněji. Při čtení těch souborů se příliš optimalizovat nedá, program ty soubory čte v neoptimalizovaném pořadí (protože ho ani nemá jak zjistit), FS musí vyhledat soubor v adresářovém stromu a FS musí vyhledat polohu bloků daného souboru v inodě. Tzn při náhodném čtení mnoha souborů je tam těch IOPS víc než při zápisu, kdy to FS může zapsat všechno naráz (po větších celcích). (Jaké přesně má optimalizace NTFS nevím, ale výše popsané platí třeba pro XFS nebo pro ext4 - delayed allocation).
které se koncentrují do disku comPodle obsazeného místa soudím, že v tom raid1 byly nejdřív disky archiv a com, které jsou plné a potom se tam přidaly ty dva další disky. Tedy ty fotky budou asi zřejmě uloženy pouze na devid 1 a devid 2 a btrfs je čte pouze z jednoho disku (proč taky ne). Celkově na té situaci nevidím nic zvláštního (teda až na poměrně creativně pojmenované disky v tom r1).
Fakticky jsem dosáhl rychlosti jen asi 50-60 MB/s což mi připadalo trochu málo.No pokud tam jsou soubory o velikosti 1MB a ten disk předpokládám 7200rpm, tak pro každý soubor je potřeba přečíst inode a potom začít číst bloky toho souboru. Tj 2 operace per soubor (a to jen pokud není fragmentovanej). 60*2 = 120 IOPS, což přesně odpovídá 7200rpm (7200rpm/60s = 120IOPS). Čtení těch rawů by mělo jít rychleji. Ono taky záleží, kde na tom disku ta data jsou, protože rychlost čtení rotačního disku na obvodu disku je nejrychlejší (to jsou úžasné hodnoty v testech) a potom to ke středu disku klesá docela znatelně. Tj disk zvládající 140MB/s může u středu klidně spadnout až pod 80MB/s.
ostatně ani to inode by nemusel číst při každé operaciPsal jsem per soubor. Program si vyžádá data souboru, FS se musí podívat na to, které bloky má přečíst (tj v inode) a potom je začne číst. To jsou dvě operace. Navíc je to btrfs, takže by si měl na druhém disku číst ještě checksum a porovnávat jej s těmi čtenými daty. Tj další operace, ale na druhém disku.
time du -a * | wc -l 105632 du -a * 0,10s user 0,42s system 99% cpu 0,524 total wc -l 0,03s user 0,31s system 64% cpu 0,523 total
Myslel jsem to tak, že by přečetl balík inode dopředu a ty měl v paměti a pak už je jen z paměti vybral.Pro x různých souborů? Ten FS neví, které další soubory bude ten program po něm chtít. Jasně, kdyby existovala možnost tomu fs říct: "připrav si všechny tyhle soubory, za chvíli je po tobě budu chtít", tak je to jiná. Ale FS tohle neumožňuje.
2k: 4194303 * 2k = 8 GiB 4k: 4194303 * 4k = 16 GiB 8k: 4194303 * 8k = 32 GiB 16k: 4194303 * 16k = 64 GiB 32k: 4194303 * 32k = 128 GiBKaždopádně je rozumné mít full backup v nějakých intervalech, protože je mnohem rychlejší obnovit full dump a dohrát pár dní transakčních logů, než dohrávat transakční logy třeba za měsíc. Obzvláště, pokud se jede na minimální rollback a každou minutu, někdy i častěji z db padají logy a za den je těch souborů třeba 15 000.
Export dat je zase v některých případech výhodný v tom, že se lze dostat k nějaké tabulce z noční zálohy do pár minut.Pokud tedy rebuild potřebných indexů nad tabulkou netrvá déle než úplná záloha/obnova.
To fakt není FS na 2GB flashku.
Tiskni
Sdílej: