Názory k článku
Kernel 4.14 LTS přináší kompresi zstd
-
meda beda (neregistrovaný)
Tak uplne ho asi nevynalezl ale povazuje se za "otce Internetu" - https://www.lupa.cz/clanky/dalsi-vynalezce-internetu/
> Když byl koncem roku 2001 v ČR na návštěvě Bill Gates, Česká televize o tom natočila reportáž, a v ní neváhala označit Billa Gatese za otce Internetu.
-
Karel (neregistrovaný)
Byly doby, kdy si to někteří místní reportéři mysleli. Přitom opak byl pravdou - Microsoft se roky snažil vybudovat vlastní konurenční síť na vlastních technologiích. Boj vzdali až s vydáním MS Windows 95, do kterých se TCP/IP stack už dal stáhnout. Od service packu 2 je to pak už součástí OS. Před tím jste museli instalovat SW třetí strany, poupulární býval například Trumpet Winsock.
-
To mate blbe. Trumpet Winsock se musel instalovat do Widli 3.1 a starsich. TCP/IP stack byl uz ve Widlich 3.11. Widle 95 ho tedy mely take, akorat ponekud zhovadily - W95 odpovidaly na ping i po te, co uvolnily z DHCP lease adresy, takze v kazde siti s W95 drive nebo pozdeji doslo k vycerpani poolu.
-
Milan Keršláger (neregistrovaný)
Trumpet Winsock se používal na Windows verze 3.x, protože byl extrémně malý. TCP/IP od Microsoftu bylo obrovské a nepoužitelné (šlo doinstalovat). Jestli si dobře pamatuji, musel jste na MS TC/IP mít 4 MB RAM, což tehdy bylo asi jako kdybyste dneska požadoval na stanici kvůli Internetu 32 GB RAM. S Trumpetkou to tehdy fungovalo i na 1 MB RAM (a navíc to umělo BOOTP!).
-
FíkZlatý podporovatelZáleží na stupni komprese. V btrfs bude zstd 1, podle následujícího benchmarku je komprese 1,5x pomalejší než lzo a dekomprese 1.2x pomalejší. Oproti zlib je naopak 4x a 1,6x rychlejší.
-
FíkZlatý podporovatel
tady mají 160 TiB: https://www.forbes.com/sites/aarontilley/2017/05/16/hpe-160-terabytes-memory
-
. . (neregistrovaný)
tohle je jádro s dlouhou podporou, myslí i na budoucnost. 8 socketová xeon monstra už dnes je možné mít s 48 TiB RAM. Podobná či vyšší čísla budou i na platformách mimo Intel (nemám tyhle maxima v hlavě).
Používají to hodně drahé stroje na vědecké účely, na modelování či nějaké ty databáze. Běžně takové mašiny se dávají třeba pod Sapí Hanu. Setkat se s tím dá i v telekomunikacích, řada brokerů, ústředen a dalších klíčových uzlů mají blackboxy, kde takovéhle extrémny lze potkat.
Osobně jsem se zatím potkal nejvýše s 2 TiB paměti, holt jsme malá země.
-
. . (neregistrovaný)
ceny za tyhle stroje jdou do milionů, desítek milionů. Ano, hotswap pamětí i cpu se používá, bez ECC to není možné provozovat.
Problém je, že tyhle systémy startují sami o sobě několik hodin poté je nutné do nich dostat data, nic na 5 minutový restart. Pokud to někdo provozuje realtime, má zálohu, v opačném případě se musí vyjednat odstávka.
Je to ale dost drahé vzhledem k tomu, že málo lidí má dostatečné zkušenosti tohle udržovat. I s menšími monstry máme problémy s interním IT.
-
j (neregistrovaný)
Uz se nekdy nekomu stalo, ze by potreboval vic nez 640kB RAM ... on shit ...
Spis teda takhle, uz se nekdy nekomu povedlo NEnarazit ve widlich na maximalni limit pouzitelny RAM jeste v dobe kdy se dana verze widli bezne prodavala ci pouzivala? Me tedy jeste ne, a to ani nepotrebuju delat s nejakejma hyperkhull strojema.
Trebas .... takovy widle ... verze 7 (tedy jeste nejaky 3 roky supportu) verze ... home "premium" (tedy prej presne to, co je urceno napriklad hracum her) ... 16GB ... lol. Jednak si uz peknych par patku muze kdokoli do desktopu napichat 64+ a druhak kdo si chce otestovat, necht vyzkousi "Gold Rush The Game" (je to teda technicky naprota hruza) ... ale skoro me vomylo kdyz sem videl 24GB zabrany ramky ... (a kazdejch 100m zasek protoze to neco nacita z pci-e SSDcka ....)
-
FíkZlatý podporovatel
Tak starší jádro chápu že nebude fungovat a grub se bude muset zstd naučit. Nestačí nekompresovat /boot, nebo samozřejmě dát /boot zvlášť?
-
1. linux montuje všetky BTRFS subvolumes rovnakou kompresiou (asi podľa prvého riadku v /etc/fstab)
2. dekomprimácia celého filesystému nepomohla, starší kernel ju i potom vôbec nevidí, nenamontuje z nej nič, ani nekomprimovanú subvolumes.Vyriešil som to takto:
- na USB s live Xubuntu som pridal práve ten kernel, ktorý mal ako aktuálny - získal som ho z vytvoreného image namontovaného do virtuálneho Xubuntu s kernelom 4.14 (loop).
- nabootoval som z USB
- upravil som bootovaciu sekvenciu aby nabootoval pridaný kernel a root partícia bola rovnaká ako pri normálnom boote (vrátane subvolume)
- zmenšil som partíciu BTRFS a vytvoril malú ext4 (som lenivým takže už online namontovanú btrfs cez Gparted)
- presunul /boot na vytvorenú ext4 partíciu
- preinštaloval grub, nastavil /boot/grub/grub.cfg, upravil /etc/fstab
Systém normálne nabehol a funguje aj s zstd kompresiou nad btrfs. Podľa mňa to ide celkom fajn. Benchmarky som nerobil. -
1. Uff, to mě docela překvapilo, ale mělo by to snad jít obejít
„You can simulate this by enabling compression on the subvolume directory and the files/directories will inherit the compression flag.“
https://btrfs.wiki.kernel.org/index.php/Compression#Can_I_set_compression_per-subvolume.3F -
FíkZlatý podporovatel
soubory na brtfs můžou mít různou kompresi, tu se kterou je to přimountováno při jeho zápisu
není tedy triviální tu kompresi měnit, btrfs wiki říká btrfs defrag -c komprese
-
Samozrejme komprimáciu partície som zmenil nielen zmenou nastavenia v fstab, ale aj defragmentáciou s parametrom -c.
Btrfs som nikdy podrobne neskúmal, ale podľa mňa btrfs obsahuje nejaké flags, podobne ako zfs. Ak sa raz nastaví že používa zstd, zmeniť sa to dá (možno) nejakými systémovými príkazmi, prípadne sa nedá vôbec (rovnako ako nieje cesta späť pri upgrade zfs). -
FíkZlatý podporovatel
já měl takový pocit, že defrag -c ne vždy kompresi změnil, už kontinuální soubory prostě nechal v původním znění
navíc na SSD defrag není žádoucí, asi je potřeba cp --reflink=auto a smazat původní soubor
flag BTRFS_FEATURE_INCOMPAT_COMPRESS_ZST to samozřejmě má, aby to starší jádro nerozhodilo
-
kdave (neregistrovaný)
To je dobra poznamka, napsal jsem k tomu neco do mailinglistu. Grub2 zatim zstd nema, ani jsem nevidel zadny patch v jejich mailinglistu.
Pokud je root se zstd (a je stale namountovany), je v tuhle chvili nutne po zmene souboru v /boot udelat rekompresi se zlib nebo lzo. Jinak je nutne nabootovat 4.14 (live/usb), namountovat root a opravit. -
FíkZlatý podporovatel
druhá možnost je používat už komprimované jádra a intramsf (pomocí třebas xz), potom btrfs to už nebude chtít komprimovat, jedině by bylo zapnuté compress-force
-
To je síce pravda, ale grub.cfg je obyčajný texťák, takže ten sa skomprimuje. Zadávať pri každom štarte systému konfiguráciu cez grub rescue je minimálne nepohodlné.
Samozrejme kernel bol komprimovaný gzipom a initramfs bol xz.
Boot partícia na BTRFS bola preto, lebo to rok bez problémov fungovalo a na 32 GB eMMC disku nie je až tak veľa zbytočného miesta, aby sa neoplatilo ho šetriť.
Kolega bol proste príliš iniciatívny, skompiloval si kernel z gentoo-sources-4.14.0 hneď ako vyšiel a hneď upravil komprimáciu v fstab a spustil defragment s paramatrom -czstd.
Problém je nateraz vyriešený, osobitná boot partícia má 256MB, zmestia sa naň 3 kernely aj s initramfs. Keď upravia grub tak, aby vedel čítať aj súbory komprimované zstd, pravdepodobne dá všetko späť. -
FíkZlatý podporovatel
asi je dobré mít /boot oddělený, se mi zdá, že grub blbne i s kompresí lzo/gzip minimálně na jednom stroji s Ubuntu, tam jsou initramfs nekomprimované a často se přebalují při různých updatech. Občas některý (zpravidla ten nejnovější) nenaběhne, grub říká, že initramfs obsahuje garbage a pak nenajde rootfs...
namountovat bez komprese a cp -r /boot /boot2; rm -rf /boot;mv /boot2 /boot to dočasně opravilo
ČLÁNKY DO MAILU