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.
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.
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!).
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ě.
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.
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 ....)
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
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).
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.
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äť.
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