Společnost OpenAI, která stojí za chatovacím robotem s umělou inteligencí (AI) ChatGPT, získala od investorů 122 miliard USD (2,6 bilionu Kč). Hodnota společnosti tak dosáhla 852 miliard dolarů (více než 18 bilionů Kč). Nejnovější kolo investování se stalo největší, jaké zatím firma uskutečnila, a peníze mají posílit ambiciózní plány rozšíření výpočetní kapacity, datových center a nábor talentů.
Nástroj k identifikaci občanů v on-line komunikaci s úřady byl dnes dopoledne zhruba dvě hodiny částečně nedostupný. Problém se objevil kolem 09:00 a podařilo se ho vyřešit kolem 11:00. Částečně nedostupná byla služba Národní identitní autority (NIA), problémy podle DIA (Digitální a informační agentura) ovlivňovaly přihlašování například i přes bankovní identitu. „Dostupnost NIA byla plně obnovena, přihlášení k digitálním službám
… více »Eben Upton oznámil další zdražení počítačů Raspberry Pi kvůli růstu cen pamětí a představil Raspberry Pi 4 s 3 GB RAM za 83,75 dolarů.
Anthropic patrně omylem zveřejnil celý zdrojový kód svého CLI nástroje Claude Code prostřednictvím přiloženého sourcemap souboru v npm balíčku. Únik odhalil doposud nijak nezveřejněné funkce jako je například režim v utajení, autonomní agent 'KAIROS', orchestrace multi‑agentů, režim snění nebo dokonce virtuální mazlíček Buddy. Zajímavostí je detekce naštvání uživatele pomocí obyčejného regexpu. Anthropic rychle odstranil sourcemap a vydal opravu, nicméně kopie kódu se již stihly na GitHubu rozšířit mezi prostým lidem.
Copilot automaticky vkládal do pull requestů 'propagační tipy', reklamní text se na GitHubu objevil ve více než jedenácti tisících pull requestech. Po vlně kritiky byla tato funkce zablokována a produktový manažer Tim Rogers připustil, že umožnit Copilotovi upravovat cizí pull requesty bez vědomí autorů byla chyba.
Je 31. března a tedy Světový den zálohování (World Backup Day). Co by se stalo, kdyby Vám právě teď odešel počítač, tablet nebo telefon, který používáte?
Digitální a informační agentura (DIA) přistupuje ke změně formátu důvěryhodného seznamu České republiky z verze TLv5 na verzi TLv6, která nastane 29. dubna 2026 v 00:00 (CET). Ke změně formátu důvěryhodných seznamů členských států (tzv. Trusted Lists) dochází na základě změn příslušné unijní legislativy. Důvěryhodné seznamy se používají v rámci informačních systémů a aplikací zejména pro účely ověřování platnosti elektronických
… více »Rspamd (Wikipedie), tj. open source systému pro filtrování nevyžádané pošty, byl vydán v nové major verzi 4.0.0. Přehled novinek v Changelogu.
SolveSpace (Wikipedie), tj. multiplatformní open source parametrický 2D/3D CAD, byl vydán v nové verzi 3.2. Přehled novinek v Changelogu na GitHubu. Vyzkoušet lze novou oficiální webovou verzi.
Organizátoři Dne IPv6, tradiční akce věnované tématům spojeným s tímto protokolem, vyhlásili Call for Abstracts. Na webu konference mohou zájemci přihlašovat příspěvky o délce 20 nebo 40 minut či 10minutové lighting talky a to až do 30. dubna. Tvůrci programu uvítají návrhy přednášek z akademického i komerčního sektoru, které mohou být technického i netechnického zaměření. Den IPv6 se letos uskuteční 4. června a místem konání bude i
… více »
jak Milos Zeman.
sda1 -----------------------+
|
btrfs --- /boot
|
sdb1 -----------------------+
sda2 --- bcache --- LUKS ---+
| |
ssd btrfs --- /
| |
sdb2 --- bcache --- LUKS ---+
Disky jsou 2x 1TB + 32GB SSD cache, vše běžné lowend připojené do SATA (to ssd má dávat 400 read/150 write MB/sec, takže na dnešní poměry nic moc), bcache jede v módu writethrough. Pocitově a podle sluchu disky méně seekují a nabíhání aplikací je svižnější. Ale není to jako mít vše rovnou na ssd, to je jiná liga. Moje idea byla, že v cache budou hlavně často používané inody, tj. často spouštěné aplikace nebo milión ini souborů KDE - to to zhruba splňuje. Při pokusu s writeback disky méně chroupaly i při zápisech, ale jak jsem psal, raději bezpečnější mód. Teď mám taky volné M.2, tak by bylo zajímavé vyzkoušet. Cache device jde odebrat a zase přidat jiné, tak až se mi dostane do ruky nějaký M.2 SSD, budu zvědavý, jaký bude rozdíl.
Já jsem kdysi používal zásadně reiser4, protože reiser4 natrhl prdel nejen všem ostatním filesystémům, ale i reiseru 3.6 (nebo jak se ta začleněná verze tenkrát jmenovala). Ale pak jsem toho nechal, protože
Zkrátka a dobře, začátkem roku 2010 už byla údržba reiser4 neudržitelná a navzdory jeho rekordnímu výkonu jsem se na něj vybodnul a začal jsem místo něj používat Btrfs, který je prostě v kernelu.
Co koukam na diskuse kolem btrfs tak se skoro cítim vysmátej, že se mi to vyhlo ...
No jasně, takhle vysmátá si připadá spousta lidí, kterým cosi zásadního nedocvaklo — a sice jak obrovský je rozdíl mezi zastaralým filesystémem typu Ext4 a filesystémem s odolností proti poškození dat, s CoW a s opravdovým RAIDem (který strčí do kapsy všechny historické pseudo-RAIDy, které po poškození dat na jediném disku začnou náhodně vracet náhodné smetí).
Zatímco ti, kterým zásadní převrat v oblasti filesystémů (zahájený ZFS) unikl, dál v poklidu ztrácejí svá data, ať už potichu nebo hlučně, jejich konkurence s Btrfs se tomu směje od ucha k uchu a dělá si jen tak pro legraci atomické snapshoty. Takže asi tak.
Pro osobní použití mám na všech svých strojích Btrfs cca od roku 2010.
No jasně, takhle vysmátá si připadá spousta lidí, kterým cosi zásadního nedocvaklo — a sice jak obrovský je rozdíl mezi zastaralým filesystémem typu Ext4 a filesystémem s odolností proti poškození dat, s CoW a s opravdovým RAIDem (který strčí do kapsy všechny historické pseudo-RAIDy, které po poškození dat na jediném disku začnou náhodně vracet náhodné smetí).
Není náhodou nutné CoW u databází vypnout?
A co RAID v LVM? Je lepší nebo horší ve srovnání s RAID v BtrFS?
A co RAID v LVM? Je lepší nebo horší ve srovnání s RAID v BtrFS?Je horší v tom, že nechecksumuje data. A lepší v tom, že na rozdíl od btrfs „RAIDu“ funguje i v degradovaném režimu a neobsahuje podivné bugy.
Horší je hlavně v tom, že při poškození dat na kterémkoliv (jednom!) disku zničí data na všech discích.
Ještě jednou: Zničí všechna data kvůli poškození dat na jednom disku.
A: A co RAID v LVM? Je lepší nebo horší ve srovnání s RAID v BtrFS?
B: Je horší v tom, že nechecksumuje data.…
C: …Horší je hlavně v tom, že při poškození dat na kterémkoliv (jednom!) disku zničí data na všech discích.Řeč byla stále o tom, v čem je lepší či horší RAID v LVM.
Není náhodou nutné CoW u databází vypnout?Doporučené to je, například dokud PostgreSQL nebude umět vhodně používat API, které se skrývá za
cp --reflink a podobnou funkcionalitou. Nutné to samozřejmě není, ale může to mít negativní vliv na výkon (v případě rotujících disků; v případě SSD to není až tolik podstatné).
A co RAID v LVM? Je lepší nebo horší ve srovnání s RAID v BtrFS?
Pozor na věc, v LVM žádný použitelný RAID není. Technologie typu dmraid i (starší) mdraid vytvářejí pseudo-RAID, který (stejně jako hardwarový pseudo-RAID) nechrání proti chybám dat na jednotlivých discích. Chyby můžou vzniknout nechtěným přepsáním části disku při údržbě systému, případně jako důsledek řady různých hardwarových a softwarových chyb.
Pokud je poškozená RAID1 replika u Btrfs, filesystém to zjistí, opraví to podle funkční repliky a nikdy nevrátí špatná data. U pseudo-RAIDu dojde k tomu, že se budou náhodně vracet nesmysly, jak se z toho RAID1 pole prokládaně čtou bloky. Jednou z jedné repliky, pak zase z jiné. Takže jakmile dojde k poškození dat, dokonce ani není zaručeno, že dvě čtení téhož souboru vrátí totéž.
RAID5 v LVM (nebo ve starém mdraidu nebo i hardwarový) je ještě horším rizikem. Dokáže se prý vyrovnat s úplným selháním jednoho disku. Ano, ale jedině za předpokladu, že ten disk přestane fungovat zcela náhle a nevrací už pak žádná data, natož neplatná. Jenže co když se na jednom disku poškodí data? Znám případ, kdy došlo k přepsání části jednoho disku nulami. Části, která neobsahovala RAID5 metadata, takže metadata tam zůstala a disk se dál tvářil jako součást RAID5 pole. A pak (bohužel) nastal resilvering, který kvůli poškození jednoho disku zničil všechna (všechna!!!) data na celém poli. Tohle by se s Btrfs nikdy nestalo, protože Btrfs má checksumy. Pozná, který blok vrací nesmysly, a ať už je ten blok pro daný stripe paritní nebo datový, problém dokáže opravit (nebo prohlásit za neopravitelný, je-li to jeden disk, RAID 0 a podobně). Nebude ale vracet náhodné smetí.
Samozřejmě to není dokonalé — jistě bude v Btrfs checksumech hashovací kolize, že ano.
Ale Btrfs prostě pomáhá tím, že snižuje pravděpodobnost vrácení poškozených dat filesystémem o nějakých deset desítkových řádů nebo víc. Takže z jevu, který by se ve větším (PB až EB) datovém centru stával často (kdyby tam byl klasický FS), se najednou stane cosi prakticky nemožného (při dnešních technologiích a kapacitách disků).
(Ještě je pro zajímavost dobré dodat, že i na jednom rotujícím disku je Btrfs bezpečnější než jiné filesystémy, protože může mít (atomicky udržované) repliky metadat. Poškozená data jsou sice neopravitelná, ale poškozená metadata se (automaticky) obnovit dají, pokud je druhá replika v pořádku. Pokud jde o SSD, tam se v Btrfs repliky metadat nedoporučují a implicitně jsou vypnuté, protože SSD má zpravidla ve svém řadiči deduplikační algoritmus, takže replikované bloky metadat by beztak nikdy nesplnily svůj účel (redundance) a řadič SSD by musel dělat copy-on-write ošklivosti při pozdější změně těch metadat.)
a s opravdovým RAIDemOpravdový RAID se pozná podle toho, že když vypadne disk, tak nejde přimountovat read-write? Nebo podle toho, že má ve status page napsáno write hole still exists, parity not checksummed?
Ale no tak.
Že by krátká paměť? Tohle jsme řešili asi pětkrát, co má splňovat opravdový RAID (a proč to, čemu se dosud říkalo RAID, ve skutečnosti nikdy nesplnilo své sliby kolem redundance). Vše jsem už pod některými tvými výkřiky vysvětloval možná i víckrát než pětkrát. Co takhle si to zkrátka dohledat a nepapouškovat pořád dokola zavádějící otázky a jiný FUD?
Pokud je o status page: Všiml sis doufám, (1) že varování se netýká RAIDu 1, 0 a jejich kombinací a (2) že status page nemusí být aktuální? Některé z oprav, o kterých ses (na status page i jinde) jistě také dočetl — jen jsi je nějak zapomněl zmínit —, už jsou nějakou dobu v kernelu.
Myslíš si opravdu, že RAID má být je něco, co se rozsype a začne vracet náhodný čaj, kdykoliv jeden jediný disk začne vracet náhodný čaj? Ne, to opravdu není RAID — to je AID be R. Btrfs přesně proti tomuhle chrání, zatímco zastaralý pseudo-RAID nikoliv (a resilveringem následně zničí všechna data — i to jsem vysvětloval několikrát).
Fakt je mi záhadou, proč se snažíš všude vtěsnat kousek FUDu proti Btrfs. Takhle v debatách fungují nejrůznější popírači IPv6, popírači systemd, popírači Btrfs, příznivci parních strojů nebo koňských povozů… Asi takhle: Pokrok v oblasti filesystémů tady bude, ať se ti to líbí nebo ne. 
Ale no tak.
Ty jsi někdy neuvěřitelně zaťatý. To, že checksumy jsou skvělá záležitost, nikdo nezpochybňuje. A to, že btrfs je schopno identifikovat porušené disky na základě chybné sumy před tím, než se disky jako celek tváří jako nefunkční, je také vynikající. Problém je v té následné funkcionalitě. Já jsem si RAIDem na btrfs zatím nehrál i když mám btrfs na mnoha discích. Nicméně, pokud btrfs se přepne do RO režimu a neumím ho přesvědčit, aby dále fungovalo normálně, je v tom něco špatně. Je to pro mne arogance vývojářů, kteří uživatele nutí do režimu, který nechtějí.
Je to trochu podobné, jako když jsme před pár lety vedli vážnivé debaty, že df pro určování volného místa na btrfs volumu nemá smysl. Tehdy jsem argumentoval, že kapacita toho disku je něco jako měřitelný prostor v matematice. Měřitelné množiny jsou mnohdy velmi divoké, v mnohadimenzinálních prostorech (i nekonečně dimenzionálních) a jde na nich zadefinovat míra. BTRFS volume je prostor o konečném množství prvků a zadefinovat smyslupnou míru by problém být neměl. Naštěstí se hodně zlepšili a v současnosti df dostačuje pro základní představu o volném místě. A pokud někdo chce a potřebuje detail tak btrfs filesystem detail odpoví. Tady už se arogance zbavili.
Druhý případ je arogance výrobců aut, kdy auto zastaví a nejede dál, protože mu někdo nevyměnil olej nebo podobnou blbost. Tady je to obdobné. Ano standardní funkcionalita na RAIDu s vypadlým diskem je extrémně riziková, na druhou stranu pokud uživatel potřebuje dočaasný čas přežít s tímto rizikem tak systém by mu to měl umožnit. Podobně jako to, když potřebuji s autem dojet, tak mi sice může nadávat a upozorňovat mne, ale musí jet. V extrémním případě může jít o život.
Dejme tomu, že mně ta funkcionalita chybí, ale v PHP ji určitě dopisovat nebudu a raději zvolím jiný filesystem.Tvoje volba.
Tohle jsme řešili asi pětkrát, co má splňovat opravdový RAIDAno, například by se tam nemělo stávat, že v nejběžnější konfiguraci po výpadku jednoho disku přestane jít používat. Pak to totiž není Redundant a Independent, ale jenom AD. To není FUD, to je prostě fakt a každý si to může zkusit.
Myslíš si opravdu, že RAID má být je něco, co se rozsype a začne vracet náhodný čaj, kdykoliv jeden jediný disk začne vracet náhodný čaj?Vzhledem k tomu, že se mi na asi 80 TB*let tohle zatím ani jednou nestalo, zatímco btrfs se mi rozsypalo několikrát, považuji za lepší používat ten „nebezpečný“ RAID. Já výhody checksumování nerozporuji, ale prostě v současném stavu není btrfs vhodný na produkci. Doporučil bych ZFS, ale tam je zase problém že zpool nejde zmenšovat a vyhazovat z něj disky.
.. treba Oracle ( puvodni autori ) , Facebook, Google , SUSE .. same malicke firmicky co nemaji dostatek lidi
Tiskni
Sdílej: