Byla vydána (𝕏) nová verze 24.7 open source firewallové a routovací platformy OPNsense (Wikipedie). Jedná se o fork pfSense postavený na FreeBSD. Kódový název OPNsense 24.7 je Thriving Tiger. Přehled novinek v příspěvku na fóru.
Binarly REsearch upozorňuje na bezpečnostní problém PKFail (YouTube) v ekosystému UEFI. Stovky modelů zařízení používají pro Secure Boot testovací Platform Key vygenerovaný American Megatrends International (AMI) a jeho privátní část byla při úniku dat prozrazena. Do milionů zařízení (seznam v pdf) po celém světě tak útočníci mohou do Secure Bootu vložit podepsaný malware. Otestovat firmware si lze na stránce pk.fail. Ukázka PoC na Linuxu na Windows na YouTube.
Mobilní operační systém /e/OS (Wikipedie) založený na Androidu / LineageOS, ale bez aplikací a služeb od Googlu, byl vydán ve verzi 2.2 (Mastodon, 𝕏). Přehled novinek na GitLabu. Vypíchnuta je rodičovská kontrola.
Společnost OpenAI představila vyhledávač SearchGPT propojující OpenAI modely umělé inteligence a informace z webů v reálném čase. Zatím jako prototyp pro vybrané uživatele. Zapsat se lze do pořadníku čekatelů.
Distribuce Linux Mint 22 „Wilma“ byla vydána. Je založená na Ubuntu 24.04 LTS, ale s desktopovým prostředím Cinnamon (aktuálně verze 6.2), příp. MATE nebo Xfce, balíkem aplikací XApp, integrací balíčků Flatpak a dalšími změnami. Více v přehledu novinek a poznámkách k vydání.
Příspěvek na blogu Truffle Security: Kdokoli může přistupovat ke smazaným a privátním repozitářům na GitHubu.
Byla vydána nová verze 14 integrovaného vývojového prostředí (IDE) Qt Creator. Podrobný přehled novinek v cgitu. Vypíchnout lze podporu rozšíření v Lua.
Byla vydána verze 1.80.0 programovacího jazyka Rust (Wikipedie). Podrobnosti v poznámkách k vydání. Vyzkoušet Rust lze například na stránce Rust by Example.
Apple oznámil, že v beta verzi spustil své Apple Maps na webu. Podporován je také webový prohlížeč Chrome. Ne však na Linuxu.
Portál Stack Overflow po roce opět vyzpovídal své uživatele, jedná se především o vývojáře softwaru, a zveřejnil detailní výsledky průzkumu. Průzkumu se letos zúčastnilo více než 65 tisíc vývojářů. Z Česka jich bylo 710. Ze Slovenska 246.
…protoze je potreba, kdyz si linux pod rukama rozfragmentuje pamet…
Tenhle kolosální nesmysl prozrazuje naprostou neznalost úplných základů, jak věci fungují.
Copak to je, taková fragmentace paměti? Jakpak s tím (ne)souvisí kernel? Kdepak to asi vzniká — snad uvnitř jednoho adresního prostoru? Nebo snad při alokaci rámců, která je ovšem fragmentovaná z principu a ze zásady a je to tak dobře…?
Ne, swap není potřeba. Kdo si myslí, že potřebuje swap, ten má obvykle něco (nebo všechno?) na svých mašinách špatně a moc jich v provozu neviděl.
Drobný hint: Tak od 256 CPU výše už swap v původní podobě totálně postrádá smysl a jeho propustnost je zoufale nedostatečná, diplomaticky řečeno. Počty CPU jsou dnes nezřídka (ba zhusta) v jednotkách tisíc na mašinu, takže co by byl v roce 2004 swap, to se v roce 2024 jmenuje úplně jinak a taky to funguje úplně jinak.
Ne, swap fragmentaci paměti nijak neřeší; nemá na ni totiž absolutně žádný vliv. Dělá asi tak jediné: Žere zbytečně SSD a chvíli skrývá problém, který je ovšem úplně jinde a který je potřeba vyřešit, nikoliv skrýt. A nemít „swap“ na SSD, nýbrž na něčem vhodnějším. A nemít starý centralizovaný swap vůbec. Atd.
20.6. 23:01
Jendа | skóre: 78
| blog: Jenda
| JO70FB
Co je spatneho na tom, ze nejaky velky vypocetni task v noci zpusobi uswapnuti databazi, kterou pouziva www v te dobe bez trafficu, zejmena kdyz je ten swap na 8GB/s server-grade nvme?Nebo třeba v mé oblasti populární, že si uživatelé nechávají otevřené ipython notebooky i když na nich zrovna nepracují.
21.6. 10:38
Jendа | skóre: 78
| blog: Jenda
| JO70FB
20.6. 23:00
Jendа | skóre: 78
| blog: Jenda
| JO70FB
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
kswapd_is_running) - a tak je system v kolecku, ze aby bylo kam davat ty anonymni stranky pro nove spousteny procesy, musi se neco uvolnovat - no a ty procesy pak vzdycky znova dozapraskaji zbytek volna skrz pagecache, cim si to akorat rekne o vic reclaim prace za nedlouho v budoucnu... takze kdyz pak prakticky nebezi kcompactd a jsou potreba vetsi bloky souvisly fyzicky pameti, budto se je povede ziskat primo v ceste alokace, nebo smula - a tam to pak zdrzuje aplikaci, nejdriv pokus o compact, pak pokus o reclaim... a kdyz pak konecne dojde na fail pri kmallocu vetsi velikosti, jeste nedavno se to projevovalo ruznou nefunkcnosti ruznych subsystemu, dokud se vsechny ty callsites nepredelaly stylem whack-a-mole na kvmalloc, kdy se po jednom neuspesnym roundu reclaimu pouzije vmalloc, kdyz nevyjde primo kmalloc... poznat takovy system jde docela jednoduse, poznavaci znak cislo jedna je relativne vysoky loadavg (a volny CPU cas) a potvrzeni prijde, kdyz si catnes /proc/buddyinfo a krom prvnich par sloupcu jsou vsude konstantne nuly, tak to je pak presne tahle situace
pritom system muze hlasit klidne 10% volny pameti, co na 2T masine je klidne tech 200G volnych, ale alokace vyssich radu failujou uplne a nez se to dostane k mensim tak proste proces stoji...
uplne nejlepsi je dat takovymu systemu zram-backed swap, protoze zram umi pracovat se 4k pages, nepotrebuje vetsi, akorat tak o velikosti tech 10% RAM... samozrejme tohle cely je poznat jenom, kdyz se na tom systemu deje neco s dostatecnou intenzitou, kdyz je to idle, tak nemaji, proc tam byt nejaky tlaky...
a btw, uz jenom pouha pritomnost swapu o velikosti jedny jediny stranky meni zasadne kalkulace pameti/watermarku, viz git grep get_nr_swap_pages, ma to docela velky vliv na vypocet working set size
[...]Opet a znovu se tvaris ze hibernace neni potreba, protoze tu mam suspend do ram...Ne, swap není potřeba. Kdo si myslí, že potřebuje swap, ten má obvykle něco (nebo všechno?) na svých mašinách špatně a moc jich v provozu neviděl.
[...][...]Dělá asi tak jediné: Žere zbytečně SSD[...]
…který řeší plno věcí za mě…
Neřeší. Právě naopak, komplikuje. Navíc HW RAID neexistuje. Údajný HW RAID je vždy AID bez R.
Partition bude následující i separe disky pro OS.
Chyba. Swap nemá smysl.
Když už, swap je soubor, ne oddíl. To aby se dal kdykoliv zvětšit / zmenšit / přidat / odstranit.
Většinou použivám souborový systém EXT4.
Chyba. Ext4 je 15+ let staré „řešení“ s 20+ let starou strukturou z dob 10GB disků, které nemá checksumy dat, redundanci ani atomické snapshoty. Do roku 2024 nepatří. Do roku 2014 taky nepatřil.
dočetl sem, že není optimální BOOT dávat do RAIDU, ale po každé změně provést synchronizaci na druhý disk
Asi by se hodilo přestat číst (nesmysly).
UEFI oddíl skutečně není důvod mít v RAIDu ani nikde na hlavních discích. Nejlépe poslouží flashdisk (zapojený třeba do interního USB). Pak na hlavních discích vůbec nemusí být ani GPT, ani jakýkoliv oddíl. O zbytečnou vrstvu méně!
Linux instalace používá standartně "mdadm"
Tak takovou fosilní instalaci rovnou zahoď. (Který to tak může být rok?) Víc škody než užitku. mdadm je zastaralá past, AID bez R, nesmysl. Nepatří ani do téhle dekády, ani do té předchozí. (V předchozí dekádě byl dmraid, ale i ten je 10+ let passé.)
…"mdadm" je možné zavést modul, který by umožňoval použít ZFS
Plácáš dohromady okurky a slony. Představ si ZFS jako čokoládovou zmrzlinu a mdadm jako hovno stejné barvy. Je to podobné? Inu, jak v čem…
- jak řešit partition boot?
Nijak. /boot je adresář a případně subvolume, ne oddíl.
- je lepší použít EXT4 nebo XFS
Není. Žebříček nejlepších řešení je:
- má smysl se zabejvat ZFS
Svoudě pvodle úrvovně dvotazu: Ne. Nemá smejsl se zabejvat ZFS.
Vobecně: Žádnej řešeněj neněj vejhvodnějšej než Btrfs. Tak tvomu pvoslednějch 10+ let bejlvo a tak tvomu ej následujejcejch 10+ let bude.
Když už, swap je soubor, ne oddíl. To aby se dal kdykoliv zvětšit / zmenšit / přidat / odstranit.Kdyz uz swap, tak rozhodne oddil a ne soubor! Zapis na partition totiz potrebuje alokace pameti a to je presne vec, ktera ti pri nedostatku pameti neprojde!
Asi by se hodilo přestat číst Andrejovy nesmysly.
Plati pokud chces na hovno vykon a maximalni problemy s RAID5/6.Žebříček nejlepších řešení je:
- Btrfs
- Btrfs
- Btrfs
- Btrfs
- Btrfs
- Btrfs
- Btrfs
- Btrfs
- Btrfs
- Btrfs
Zapis na partition totiz potrebuje alokace pameti a to je presne vec, ktera ti pri nedostatku pameti neprojde!Já doufám že se swap v souboru předalokuje. A proto taky když máš swap soubor na btrfs, tak nefungují některé funkce toho FS. Je to lepší než jsem čekal (některá omezení se týkají jen toho souboru), ale zrovna v případě tazatele to nefunguje - píšou tam, že FS se swapem nemůže být multidevice (RAID1). (tohle hezky ilustruje, jak Andrej vždycky začne vidět rudě a napíše jak je řešením btrfs, aniž by si ověřil, že btrfs opravdu podporuje požadovaný use-case)
Swap rozhodně do „starého železa” nepatří, pokud nemáš opravdu hodně RAM. A mít ho jako soubor na FS je největší hovadina, hodná MS Windows. Jakmile totiž začne „vařit” nějaká aplikace co pracuje s FS, tak to ubije všechno. Zrovna včera jsem měl takový zážitek s Ubuntu, při zcela banální operaci – rušení dvou předchozích uživatelů stroje a zavedení nového.
U sebe na stroji používám Btrfs v raid1, s tím že z každého 1TB mSATA mám 930GB na data a 16 GB pro swap. Vzhledem k tomu, že mám 16GB RAM, mohu (pokud chci) systém uspat na disk, ale hlavně mohu bez problémů pracovat v Gimpu s velkými soubory, bez rizika že by při tom došlo ke zhroucení kvůli nedostatku RAM.
A swap je velice výhodný i u disklessových strojů s overlayem, které soubory ukládají do RAM (tmpfs). Swap také umožňuje dělat různé kejkle při virtualizaci, neboť umožňuje nakecat virtuálu třeba i to, že má k dispozici. 32GB RAM, ač má reálně ten fyzický stroj k dispozici jen 8 GB.
A nevadí na SSD disku, když dám SWAP jako partition, že bude furt dokola přepisovat jen jedno místo?No moment, zápisy na SSD přece fungují obdobně, jako je CoW. Prostě se z operačního systému nedá záměrně strefit dvakrát do stejného místa disku. To ošetřuje firmware disku. Jinak by se dalo SSD za minutu odpálit. To by se to reklamovalo...
Swap je swap a soubor je soubor. Swapovací oddíl je vyhrazený kus úložiště, do kterého ti FS nehrabe a kam se odlívají data, když je potřeba uvolnit RAM. Pokud nemáš zapnutý swap, uvolní kernel RAM tak, že zabije nějaké procesy. A to nechceš.
Pokud swapuješ do souboru, chová se k němu FS jako k souboru, pokud mu výslovně neřekneš, aby ten soubor byl nocow. Výsledkem je, že ti začnou IO operace blokovat systém. Jádro bude chtít odsypat RAM do swapu, ale bude muset čekat, až mu dá ovladač FS zelenou.
Pokud swapuješ do souboru, chová se k němu FS jako k souboru, pokud mu výslovně neřekneš, aby ten soubor byl nocow.Tak zrovna na btrfs, o kterém se píše v tomto vláknu, onen swapovací soubor musí být nocow. Jinak to nefunguje. Kromě toho musí mít to btrfs single profile a single device. Takže na raidu to jaksi nefunguje. Sice se to dá nějakými machinacemi oblbnout, ale má to výkonnostní (a možná i jiné) důsledky.
UEFI oddíl skutečně není důvod mít v RAIDu ani nikde na hlavních discích. Nejlépe poslouží flashdisk (zapojený třeba do interního USB). Pak na hlavních discích vůbec nemusí být ani GPT, ani jakýkoliv oddíl. O zbytečnou vrstvu méně!Toto mne opravdu zajímá! Mohl bys mi prosím poradit, jak toho docílím? Líbilo by se mi mít zavaděč na USB flešce a disky bez GPT či MBR, pouze s BTRFS či ZFS. Případně je na toto někde na internetu nějaké howto? Linux již používám docela dlouho, ale toto bych sám bez pomoci nedal. Moc díky, Karel
To že něco dlouho používáš nezakládá nic pro to, abys takové věci znal. Drtivá většina uživatelů linuxu nemá vůbec tušení jak zavádění funguje.
Jestli chceš mít zavaděč na USB flešce, není nic jednoduššího. Vyrob si nějakou instalačku s podporou UEFI, pak si na ni nainstaluj zavaděč a podle toho co použiješ si nastav co a jak budeš spouštět. Já si takhle v nouzi upravil instalačku MS Windows, protože jsem žádné jiné bootovací USB zrovna po ruce neměl, a potřeboval jsem pořešit nabouraný MS Surface, který jinou možnost než nabootovat z USB nemá.
Já UEFI pro zavádění nepoužívám. Disky mám 2x 1TB takže není důvod kašpárkovat s GPT a situaci komplikovat. Instaluji GRUB do MBR.. Pochopitelně na oba disky, pro případ, že by jeden exnul. Pokud používáš UEFI, stačí, jak už bylo uvedeno v téhle diskuzi, syncovat ten UEFI oddíl ty další disky. Je úplně fuk, který se při zavádění chytne, protože grub co se instaluje do EFI už není limitovaný moduly které co do něj nastrkáš. Dřív si je musel nacpat do poměrně omezeného prostoru.
dočetl sem, že není optimální BOOT dávat do RAIDU/boot je v pohodě dávat do RAIDu, co ale nejde dát (teda, hypoteticky by mohly s verzí metadat 0.91/1.0, a lidi níže píšou že to funguje) do RAIDu je UEFI oddíl. Ale to je v pohodě, stačí "nainstalovat GRUB" na oba disky (což ve skutečnosti vytvoří GRUB EFI binárku); Debian na to má možná i automatiku, že se při instalaci GRUBu zeptá, na které disky ho chceš nainstalovat. To by se mělo správně opakovat po každé aktualizaci GRUBu (což když se ta automatika správně nastaví, tak se stane), ale ve skutečnosti to je dost kompatibilní na to, aby to nabootovalo i když to neuděláš.
Všechny tři zmiňované partiton bych rád měl v RAID1Doporučil bych udělat na začátku ty EFI oddíly a pak jen jeden RAID a v něm LVM. V něm si pak vytvoříš uvedené (root, swap) jako LV. Je to lepší protože to pak půjde snadno zvětšovat, zmenšovat, snapshotovat. Jako FS používám ext4, hlavně protože věřím, že je víc testovaný a odladěný. Ale XFS je také dost rozšířený, takže je to taky v pohodě, a jeho výhoda AFAIK je, že nemá při vytváření staticky alokované inody ("omezený počet souborů"). ZFS a další pokročilé FS bych nedoporučoval pokud nejsi připraven si to nastudovat. A když už, tak bych pak zvážil jeho použití přímo s integrovaným "RAIDem", ne nad MD.
teda, hypoteticky by mohly s verzí metadat 0.91/1.0
Těžko říct, jestli to se starými metadaty na konci funguje, prý jo.
Zcela bez metadat to funguje, ale sám za sebe můžu říct jediné: už nikdy více. Je to v.o.s.e.r. Jako první to vymyslel nizozemský sysadmin Johan van der Praase a od té doby to šlo od desíti k pěti.
Nedivím se, že to systemd nechce „fixnout“ .
…a pak jen jeden RAID…
…který by byl k ničemu, i kdyby existoval, jenže ono nic takového neexistuje…
…a v něm LVM…
…který je přímo dvojnásob k ničemu. Ztráta flexibility pro nic za nic, nulový přínos.
Jako FS používám ext4, hlavně protože věřím, že je víc testovaný a odladěný.
Kdy už tenhle omyl zmizí, to je ve hvězdách. Císař Franta Pepa I. říkal, že automobil nebude nikdy podstatný, protože je to prý sice hezká hračka, ale každý bude dál jezdit na koni. Jenže Franta Pepa I. tenkrát ještě neviděl 10+ úspěšných let automobilismu, pročež mu lze takové hloupé mínění odpustit…
…a jeho výhoda AFAIK je, že nemá při vytváření staticky alokované inody ("omezený počet souborů").
Co si asi vojín Kefalín představuje pod takovým pojmem výhoda?
ZFS a další pokročilé FS bych nedoporučoval pokud nejsi připraven si to nastudovat.
Velocipéd a další pokročilé dopravní prostředky (motocykl, neřkuli automobil) bych nedoporučoval, pokud nejsi připraven si to nastudovat. Jezdi „normálně“ na koni, případně (ještě lépe) na oslíkovi.
B.o.ž.í.n.k.u. Co přesně je potřeba nastudovat pro použití Btrfs, abych tam mohl udělat třeba mkdir? Nějaký zvláštní, jiný mkdir? Nějak jsem si toho nevšiml.
Kdyby někdo přišel k Btrfs jako slepý k houslím tak, že se někde v instalátoru změní řetězec exniužkonečně4 na btrfs, vůbec by si toho nevšiml. Prostě by to kliďánko mohl používat jako úplně kterýkoliv jiný souborový systém. Později, až by se mu zachtělo nějakých vylepšení, řekl by si:
Leč pokud nebude mít Btrfs, řekne si potom tak jedině: A doprdele. Mám hovno.
A když už, tak bych pak zvážil jeho použití přímo s integrovaným "RAIDem", ne nad MD.
Matení tazatele. /o\ Tady není nic ke zvážení. Použití normálních souborových systémů (tedy Btrfs nebo ZFS) vylučuje jakýkoliv AID bez R a odpady typu mdadm nebo dmraid. Jinak je výsledek nedefinovaný. Souborový systém s volume managementem může (a musí) používat jedině svůj vestavěný volume management.
vůbec by si toho nevšimlJá si toho všiml v okamžiku, kdy se porušila konzistence, a zjistil jsem, že to nemá funkční fsck.
Stokrát se tady tenhle opakovaný nesmysl řešil. Tak si to budeme muset zase celé zopakovat, což?
Já si toho všiml v okamžiku, kdy se porušila konzistence, a zjistil jsem, že to nemá funkční fsck.
S čím srovnáváš? ← Tuhle otázku jsi ještě nikdy nebyl schopen zdpovědět. Kde je ten funkční fsck? Yeti už byl viděn!
Sračka4 nemá funkční fsck, protože nemá žádné checksumy dat. Tudíž poškození dat na Sračce4 vůbec nezjistíš, natož abys ho mohl zkoušet opravit.
Když dojde na neplatný checksum, pak (Stating The Obvious) platí některá z následujících tvrzení:
Tak. Už? Inu, není od věci dát si na tohle témě každý rok opáčko, že ano. Btrfs rulezzz.
(Proč se vlastně nikdo nenaváží do ZFS, že taky nemá ten zbytečný fsck z 90. let? Pochop, kdo můžeš.)
Tuhle otázku jsi ještě nikdy nebyl schopen zdpovědět. Kde je ten funkční fsck? Yeti už byl viděn!Zodpověděl. Funkční fsck je nástroj, který nekonzistentní FS uvede do konzistentního stavu, pokud možno s minimální ztrátou dat a s možnostmi jejich obnovení (např. řekne co je postiženo).
Sračka4 nemá funkční fsck, protože nemá žádné checksumy dat.Ovšem my hovoříme o konzistenci metadat (stromová struktura, alokované bloky a tak).
Když dojde na neplatný checksumPřípady které jsem řešil (corrupt leaf při přístupu k souboru, scrub projde v pořádku) i které byly probírány zde na fóru (např.) se vyznačují tím, že nedošlo k neplatnému checksumu.
Máš nabouraný hardware (RAM, sběrnice, disk/SSD), který žere data. Pak můžeš být rád za včasné varování! Výmluvy typu „ale Sračka4 mi tam fungovala!“ jsou tupé + liché. Ano, „fungovala“, jen tu a tam obohatila data nějakou tou náhodou.OK, stalo se mi to, memtest prošel v pohodě, co mám dělat dál? Vyhodit celý počítač do popelnice, smazat disky, nalejt tam data ze zálohy a zkusit to znova?
Když máš hardware nabouraný jen trochu — například se problém týká jen jednoho z disků v redundantní konfiguraci —, opět Btrfs vyhraje nad Sračkou4, protože dokáže poškozená data obnovit z redundance.Znovu, hovoříme o konzistenci FS (která může být narušena například softwarovou chybou (buď v samotném FS, nebo něčím nesouvisejícím co poškodí paměť v kernelu) nebo chybou RAM či CPU), ne o silent data corruption na disku.
OK, stalo se mi to, memtest prošel v pohodě, co mám dělat dál? Vyhodit celý počítač do popelnice, smazat disky, nalejt tam data ze zálohy a zkusit to znova?
Ano. Soucit stranou. I kolenovrt by si měl uvědomit, že používání takového počítače vede k těžko řešitelným problémům.
Případy které jsem řešil (corrupt leaf při přístupu k souboru, scrub projde v pořádku) i které byly probírány zde na fóru (např.) se vyznačují tím, že nedošlo k neplatnému checksumu.Odkazovanou diskusi jsem tedy pochopil úplně jinak. Asi takto: - máme tady hardware, který používá souborový systém btrfs - hardware je nějakým způsobem vadný - btrfs při používání vypisuje informativní hlášky, že dochází k chybám při přístupu na hardware - hardware vytuhne - po nějakých machinacích hardware znovu nastartuje a opět funguje, přičemž souborový systém btrfs uchoval všechna data bez poškození
hardware je nějakým způsobem vadnýTechnicky vzato může být nějakým způsobem vadný veškerý HW, ve smyslu že občas udělá chybu. Hodně pomůže (avšak ne zcela vyřeší - jsou tu i další komponenty co mohou selhat) ECC paměť, ale tu nemá většina desktopů a snad žádný notebook.
Zajímavé také je, že společným jmenovatelem problémů, co se tu ohledně BTRFS řešily, je nvme od Samsungu.Nebyla jedna z hlavních propagovaných vlastností btrfs, že má díky svým checksumům proti chybám disku chránit (resp. je scrub má alespoň detekovat)?
No, protože upozorňuje na chybu, jinak by to neřešili. A řeší se problém s checksummy (btrfs scrub), tak i se strukturou (btrfs check).Odkazované a zde řešené problémy se vyznačovaly tím, že scrub vždy prošel bez chyby.
Nevím, jestli to ještě dnes platí, ale já si toho při svém prvním (a zároveň posledním) použití BTRFS všiml při mnohem běžnějším problému - když došlo na disku místo. Člověk by řekl banální věc, ale s BTRFS to tenkrát byla konečná - na rozdíl od toho "špatného" ext4, kde se prostě data smažou a jede se dál, BTRFS pro smazání dat potřebovalo...volné místo na disku! Strávil jsem tenkrát den s BTRFS toolama (nic nefungovalo) a zakončil to pokusem o rozšíření FS na USB disk, kdy se slavné BTRFS definitivně sesypalo...
Od té doby mi BTRFS už tak zázračné nepřijde a držím se ext4, se kterým jsem nikdy neměl žádný problém i přes množství kernel paniců, kterým ho neustále vystavuju.
Věřím, že dnes již to bude lepší, ale zase to není tak dávno, abych tím nemohl zpochybnit výroky zdejších BTRFS-Hujerů, jako že: "ext4... Do roku 2024 nepatří. Do roku 2014 taky nepatřil". Protože v roce 2015 byla realita taková, že BTRFS/jeho tooly prostě podobně zásadní bugy měly. A tu složitost/režii má BTRFS stále, takže na spoustu věcí se i dnes ext4 může hodit víc, než BTRFS.
Ale jasně, kdybych měl dneska stavět nějaký "enterprise" serverový diskový pole s RAIDem, tak asi taky šáhnu po BTRFS, nebo věcech od RedHatu postavených nad XFS.
Protože v roce 2015 byla realita taková, že BTRFS/jeho tooly prostě podobně zásadní bugy měly.
Pepi! Sorry, ale nemáš pravdu. Stejně jako Žako zaměňuješ hrušky s jabkama. Tooly nejsou ovladače FS, jenom nástroje pro jeho správu. Btrfs, naformátované před víc jak 10 lety jede dodnes bez sebemenších problémů. A to se v něm mezitím vystřídalo za tu dobu hned několik typů blokových zařízení a disků nejrůznějšího typu. Původně single device nad MD raidem, nyní multidevice v raid1 módu.
Jediný FS, který mne kdy připravil o data byl Ext4, před 12 lety. Kdybych tam měl už tehdy Btrfs, nikdy by k tomu nedošlo, protože bych viděl, že se děje něco špatného dřív, než jsem ten stroj restartoval.
Tooly nejsou ovladače FS
Nic takového netvrdím, to je zas jenom tvá proslulá neschopnost porozumět psanému textu (není divu, že tě vyhodili ze čtyř univerzit...). Ale BTRFS, ostatně stejně jako prakticky jakýkoliv jiný FS, není jenom ten ovladač v jádře, ale právě i ty tooly, bez kterých ten FS ani nevytvoříš.
Pepi nehul. Ptákům to nesvědčí. Svcrkává se jim už tak malý mozek. Nebudu ztrácet jako Max čas tím, abych ti vysvětloval co je FS a jak se s tím pracuje. Dovzdělat ses měl už tenkrát, před lety, a neměl by si s Btrfs žádný problém.
Maxi, nemá smysl ztrácet čas s papouchama. Žako a Pepi umí akorát papouškovat zaslechnuté kraviny. Sami s těmito technologiemi žádné reálné zkušenosti nemají.
Jinak jsi se asi se ZFS nesetkal, jinak by jsi netvrdil, že je složitější pro správu.
Nutnost řešit externí repozitáře a DKMS je rozhodně složitější, než nic. Což je přesně to co musíš dělat v případě FS které máš out-of-the-box v distribuci. A o rozdílech ve správě disků/data setů bychom také mohli polemizovat
To s tím výkonem také nechápu. Pokud tě nezajímá výkon, tak zvolíš ext4? Spíše naopak, ne?
Přečti si ten příspěvek, na který reaguješ ještě jednou a pořádně...
Jak enterprise storage souvisí s OS, to mi uniká. Stavím něco, co má mít nějaké parametry, podle toho vyberu technologii (včetně OS).
Ne každý se chce/může zabývat Solarisem nebo FreeBSD. Ten OS na kterém ti to poběží je poměrně zásadní argument. Když máš veškeré servery na RHEL, budeš logicky chtít na RHEL i storage server, protože už na to máš dodavatele a lidi co tomu rozumí. Ty máš možná na každou věc zcela odlišný a specializovaný SW/HW, ale minimálně chápat tu snahu těch "enterprise" firem mít tu infrastrukturu konzistentní by si mohl.
to je vyjadrovani ze by si clovek uz i myslel, kolik je tady sectelych odborniku na vsechno... a pak se clovek docte, ze XFS je pred ext4 na svetelne roky jenom kvuli tomu, ze nema staticky pocet inodes to jako fakt? :D hele borci, vam to tady takhle jakoze vyhovuje tady mezi sebou takhle traparit, to vam jako staci jo, v zivote netreba dokazat vic, nez umet kvalitne zamachrovat na portalu, kde zbylo dalsich 10 podobnych? wow
jeden frajirek vetsi, nez druhej, ale tyvole, umi to absolutni hovno... hlavne ho umet spravne nalakovat, zejo vis vtipnerku, ja sem nechodim delat kategoricky statementy o technologiich, kterym nerozumim a v kterych mi ujel vlak, jako vy soudruzi tady tobe to muze mozna pripadat jako nedostatek argumentu, o to vetsi zabava, kdyz vidim, jak se v tom placate max zatim vede, jako jedinej z tech, do koho se rad trefuju, aspon uzna, ze mam pravdu (coz arguably trochu bere motivaci se do nej trefovat do budoucna a tak by to asi melo bejt, ne? :D)
a dik za starost, mozna ale zas vykecavas tou svoji projekci o plinach o sobe vic, nez bys chtel... beru tak, ze mi to cpes hlavne proto, ze tobe ty pliny ta almuzna z CVUT nezaplati, ale jejich potreba uz se blizi, ze
pojd vynaleznout jeste nejaky kolo, at mas tady mezi dalsima nulama z ceho zit az do smrti
ja se u toho kralovsky bavim, pojd, poskrabej jeste to dno, treba z nej jeste dostanes nejakou dalsi urazku, co jsi celyho pul dne nepouzil
jedina bolistka, ktera by pritom realne potrebovala vyresit, je tvuj vlastni pocit zbytecnosti, z kteryho se pak stava... tvoji necinnosti... smutna realita :) a tak si prsek, pindej, ja ti zas vzdycky prijdu pripomenout, jak zbytecnej jsi...
treba bys taky mohl zkusit obmenit zasobu tech nadavek, tocis asi 5 furt dokola, takovy cely neoriginalni a bez napadu, jak ty sam celej
heh jste to ale sebranka
... vitr do plachet byste tomuhle anonymnimu trollingu sebrali jinak, ale to ty mega ega proste nedovolej, zejo mohli jste to davno vsichni nechat bejt, ale ne, vy se v tech svejch hovnech budete rejpat dal, no tak vam naserviruju klidne dalsi, kdyz si v tom tak rochnite a jeste u toho tak spokojene kejhate, vy potrefeny husy...
aha, ja vim, kdesi davno zahozenej pri registraci tady do ty zumpy, protoze pusobit tady s takovym vystupovanim pod vlastnim jmenem... prej kdo se ztrapnuje
btw, mlcet jste mohli davno, nebylo by tady, co rozmazavat to ty nicim nepodlozeny megaega ale holt nikdy nedovoli no
prej kdo se ztrapnuje
Ty
Zcela bez metadat to funguje, ale sám za sebe můžu říct jediné: už nikdy více.Ještě mě napadlo, že pokud máš dva samostatné "EFI" oddíly, tak se musí do efi vars přidat dva záznamy (kdyby jeden disk umřel, tak aby to nabootovalo z toho druhého), případně to instalovat jako portable. Nemám zkušenost jestli to přidání obou disků grub-install běžně dělá.
20.6. 00:30
3.6. 05:54
23.6. 12:26
grub-install --no-bootsector --no-nvram --removable --target=x86_64-efi --efi-directory=/boot/efi
grub-install --target=x86_64-efi --efi-directory=/efi0 --no-nvram --removable
efi mountpointy mam ve fstabu noauto a efivars jako ro
Každé „rozjíždění“ souvisí s tím, že pokud se na webu povalují naprosté kraviny a nikdo jim neoponuje, nakonec ty kraviny proniknou do jakéhosi všeobecného povědomí. Což je škoda.
Proto je dobré kravinám vždy oponovat, i když je to svým způsobem marné: pokud byl někdo posledních 10+ let dokonale imunní vůči argumentům, dalších 10+ let to nebude jinak.
Leč ono nikdy nejde o toho či onoho šiřitele FUDu. Vždy jde hlavně o tu „tichou většinu“, která si během následujících měsíců a let příslušné vlákno přečte. Ta je cílovým publikem.
Pokud budou mít kraviny + kravince všude poslední slovo bez opozice, leckdo je bez přemýšlení přijme jako fakta. Pokud jim někdo oponuje, vede to (snad) (některé) čtenáře aspoň k zamyšlení.
Pokud budou mít kraviny + kravince všude poslední slovo bez opozice, leckdo je bez přemýšlení přijme jako fakta. Pokud jim někdo oponuje, vede to (snad) (některé) čtenáře aspoň k zamyšlení.
Plně souhlasím. Jenom bych dodal, že mezi omylem a kravinou není rozdíl. Takže každá validní informace, která vede k objasnění podstaty, je na místě.
A řekl bych, že by se Andrej takhle nerozjel, kdyby sem někteří nezačali pastovat již tisíckrát omleté blbosti. Sám na podobné dotazy již dávno nereaguji – informací na tohle téma už je tady dost. Ať se dotyčný také trochu namáhá s jejich vyhledáním.
[...]To by se mělo správně opakovat po každé aktualizaci GRUBu[...]nevim jak/zda Debiani automatika, ale v *buntu mam reseno pridanim /etc/grub.d/99_sync_efi:
#!/bin/sh
set -e
efi2="/boot/efi2"
efi2_uuid="EF02-EF02"
echo "Sync EFI to ${efi2} (${efi2_uuid})..." >&2
mkdir -p ${efi2}
mountpoint -q ${efi2} || mount /dev/disk/by-uuid/${efi2_uuid} ${efi2}
rsync -a --delete /boot/efi/ ${efi2}/
Na Debianu 12 viz obrázek v příloze
Po instalaci nabootujes a zjistíš, že systém používá pouze jednu EFI partition, takže tu druhou si vytvoříš ručně:
root@debian:~# blkid | grep vfat /dev/sdb1: UUID="EB2B-F115" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="5e8fcaf7-6aa4-4147-adfa-46fe0352a54f" /dev/sda1: UUID="EB2B-08D9" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="7f02c36e-ea1f-426d-878b-4ff286e8b363" root@debian:~# grep vfat /etc/fstab UUID=EB2B-08D9 /boot/efi vfat umask=0077 0 1 UUID=EB2B-F115 /boot/efi2 vfat umask=0077 0 1 root@debian:~# mkdir /boot/efi2 root@debian:~# mount -a -vvv / : ignoruje se /boot/efi : již připojeno /boot/efi2 : úspěšně připojeno /media/cdrom0 : ignoruje se root@debian:~# grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=debian Installing for x86_64-efi platform. Installation finished. No error reported. root@debian:~# update-grub root@debian:~# grub-install --target=x86_64-efi --efi-directory=/boot/efi2 --bootloader-id=debian2 Installing for x86_64-efi platform. Installation finished. No error reported. root@debian:~# update-grub root@debian:~# efibootmgr | grep debian Boot0005* debian Boot0007* debian2Podobně funguje např. na Fedoře a Ubuntu Serveru. U desktopových Ubuntu a Linux Mint instalatorů instalace na RAID s EFI většinou selže.
root@debianbox:~# grep efi /etc/fstab # /boot/efi was on /dev/sda1 during installation UUID=EB2B-08D9 /boot/efi vfat umask=0077,nofail 0 1 UUID=EE47-B62A /boot/efi2 vfat umask=0077,nofail 0 1
Tiskni
Sdílej:
