Byla vydána verze 0.2.0 v Rustu napsaného frameworku Pingora pro vytváření rychlých, spolehlivých a programovatelných síťových systémů. Společnost Cloudflare jej letos v únoru uvolnila pod licencí Apache 2.0.
Open source RDP (Remote Desktop Protocol) server xrdp (Wikipedie) byl vydán ve verzi 0.10.0. Z novinek je vypíchnuta podpora GFX (Graphic Pipeline Extension). Nová větev řeší také několik bezpečnostních chyb.
Rocky Linux byl vydán v nové stabilní verzi 9.4. Přehled novinek v poznámkách k vydání.
Dellu byla odcizena databáze zákazníků (jméno, adresa, seznam zakoupených produktů) [Customer Care, Bleeping Computer].
V lednu byl otevřen editor kódů Zed od autorů editoru Atom a Tree-sitter. Tenkrát běžel pouze na macOS. Byl napevno svázán s Metalem. Situace se ale postupně mění. V aktuálním příspěvku Kdy Zed na Linuxu? na blogu Zedu vývojáři popisují aktuální stav. Blíží se alfa verze.
O víkendu 11. a 12. května lze navštívit Maker Faire Prague, festival plný workshopů, interaktivních činností a především nadšených a zvídavých lidí.
Byl vydán Fedora Asahi Remix 40, tj. linuxová distribuce pro Apple Silicon vycházející z Fedora Linuxu 40.
Představena byla služba Raspberry Pi Connect usnadňující vzdálený grafický přístup k vašim Raspberry Pi z webového prohlížeče. Odkudkoli. Zdarma. Zatím v beta verzi. Detaily v dokumentaci.
Byla vydána verze R14.1.2 desktopového prostředí Trinity Desktop Environment (TDE, fork KDE 3.5). Přehled novinek v poznámkách k vydání, podrobnosti v seznamu změn.
Dnešním dnem lze již také v Česku nakupovat na Google Store (telefony a sluchátka Google Pixel).
jinak nejak nechapu to madam raid1 a z toho btrfs raid10, to je nejaka velka podivnost, ne?
Přesně to mě taky napadlo. Kombinovat mdadm (pseudo-RAID, který by si měl správně říkat „AID“, nikoliv RAID, protože nemá checksumy a nedovede tedy zjistit, která z replik selhala) a Btrfs (kde lze nastavit opravdový RAID) je dost zrádné. Iluze redundance je totiž horší než úplná absence redundance, protože o tom druhém člověk obvykle aspoň ví. 
RAID10 je nejlepší nastavit pouze a výhradně pomocí Btrfs, bez jakýchkoliv ubohých „AIDů“ bez „R“ (hardwarový (R)AID, mdadm, dmadm), které při silent data corruption nenávratně ztratí data, místo aby před tímto (stále častějším) problémem chránily.
24.8.2017 03:47
Jendа | skóre: 78
| blog: Jenda
| JO70FB
Ještě důležitější otázka je, proč si někdo (naprosto chybně) myslí, že k poškození dat může dojít jenom v paměti, na disku nebo na SATA. Jako by snad chyba v softwaru nebo (především!) lidská chyba nebyla mnohem pravděpodobnější a častější příčinou problémů. Znám hned několik smutných historek o přepsání jednoho (jednoho!) disku nulami (a nechme stranou, proč někdo takový krok podnikl — zkrátka lidský faktor), které poslalo celý AID5 (chybně zvaný RAID5) do kytek, tedy ztratila se všechna data. Ještě jednou, třikrát podtrhuji: AID5 ztratí všechna data kvůli poškození dat na jednom disku. Co může být horší než tohle? A co teprve AID6 — to je teprve lahůdka! AID6 se dá poslat do kytek přepsáním jednoho disku nulami, nikoliv dvou disků. Slibovaná redundance neexistuje.
Ještě zajímavější paradox: AID1 by měl být teoreticky redundantní, že ano. 
Takže bez problémů ustojí, když na jedné replice přepíšu všechny bloky nulami? Nebude mi pak doufám náhodně prokládaně číst nulové bloky, že ne? Ouha, bude.
Proti téhle^^^ ubohé iluzi redundance je Btrfs jedno z mála řešení, které dává smysl. Jistě, ZFS je taky možnost a spousta lidí mu dává přednost, protože doufají, že je "stabilnější" (ať už to znamená cokoliv). Nevím, komu kde totálně "zhavaroval" Btrfs, a nehodlám se zabývat anekdotami z roku 2010, historkami o kernelu 3.1 nebo něčím podobným.
27.8.2017 10:56
Jendа | skóre: 78
| blog: Jenda
| JO70FB
Tak především, silent data corruption je v každém větším úložišti naprosto běžný jevPak asi mých několik desítek TB není „každé větší úložiště“.
Jako by snad chyba v softwaruNapříklad v mnohem komplikovanějším a po 5 letech po označení za stabilní stále neodladěném FS?
nebo (především!) lidská chybaJednak si nedokážu moc představit tento typ chyby a jednak btrfs zjevně není odolné proti poškození konzistence a scrub to neodhalí.
Znám hned několik smutných historek o přepsání jednoho (jednoho!) disku nulamiTo mdadm nesloží, protože tam prostě nebudou metadata. Že někdo používá shitový HW RAID kterému se tohle stane je jeho problém.
Nevím, komu kde totálně "zhavaroval" Btrfs, a nehodlám se zabývat anekdotami z roku 2010, historkami o kernelu 3.1 nebo něčím podobným.Mně, šlo o kernely 3.19 a 4.4, a bylo to v letech 2015-2017.
Pak asi mých několik desítek TB není „každé větší úložiště“.
Ne, tvé desítky TB nejsou větší úložiště. Větší úložiště mají PB, případně (bavíme-li se o větších "internetových" firmách) EB.
Například v mnohem komplikovanějším a po 5 letech po označení za stabilní stále neodladěném FS?
Tahle údajná neodladěnost je slovíčkaření. Není jasná definice takového pojmu. Ext4 měl v nedávné době několik zásadních bugů spojených se ztrátou dat, ale pořád se najdou exoti, kteří řeknou, že Ext4 je "odladěný", zatímco Btrfs ne. Takové označování prostě nedává smysl.
Jednak si nedokážu moc představit tento typ chyby a jednak btrfs zjevně není odolné proti poškození konzistence a scrub to neodhalí.
Ten typ lidské chyby jsem velmi jasně a názorně popsal. Btrfs samozřejmě je odolný proti problémům s konzistencí dat a jejich poškození odhalí. Ten zázrak se jmenuje checksumy. Chyby odhalí nejen scrub, ale i pouhý pokus přečíst poškozená data. To je nakonec nejdůležitější, že Btrfs nevrací poškozená data, na rozdíl například od Ext4, který rád vrací rozsypaný čaj. Takže první část výroku je asi z nepozornosti při četní a druhá část je prostě fakticky špatně.
To mdadm nesloží, protože tam prostě nebudou metadata. Že někdo používá shitový HW RAID kterému se tohle stane je jeho problém.
Zase nesmysly. Zaprvé, disk se nemusí nutně přepsat od začátku. Zadruhé, metadata/superblok nemusí být na začátku; u starších polí bude na konci. Než se disk přepíše, úžasný chytrý AID5 zahájí resilvering. Ani nemusí jít o přepsání namountovaného disku za provozu. Nehoda, kterou jsem zmiňoval, se stala mimo provoz. Disk se přepsal částečně. Metadata na něm samozřejmě zůstala. A pak nastal mount, resilvering a odchod všech dat do věčných lovišť. A vykládej mi, jak to mdadm nesloží.
Mimochodem, proč se dělají crash testy u aut? Když někdo řídí auto, které není bezpečné, je to přece jen a jen jeho problém, ne? Tohle je zvrácená logika. Pokud můžeš mít mnohem lepší zabezpečení dat, bez zhoršení jiných parametrů, neexistuje důvod ho nemít. I kdyby sis nakrásně myslel, že se nikdy nikdo nemůže zmýlit výše popsaným způsobem.
Mně, šlo o kernely 3.19 a 4.4, a bylo to v letech 2015-2017.
Ano, to jsou smutné příhody (hlavně ta na StackExchange), ale například zběžné hledání kritických chyb a ztrát dat v Ext4 vrátí podobných anekdot o poznání víc. Kdybych se měl řídit anekdotami, asi bych nepoužíval žádný filesystém a video bych si kreslil v obrázcích na papír.
27.8.2017 12:50
Jendа | skóre: 78
| blog: Jenda
| JO70FB
Btrfs samozřejmě je odolný proti problémům s konzistencí dat a jejich poškození odhalí.Neodhalí, viděl jsem zjevně poškozené filesystémy, které vracely chyby při čtení a scrub proběhl bez chyb.
u starších polí bude na konciHistorky z roku 2010 nás nezajímají ;)
Btrfs samozřejmě je odolný proti problémům s konzistencí dat a jejich poškození odhalí.Neodhalí, viděl jsem zjevně poškozené filesystémy, které vracely chyby při čtení a scrub proběhl bez chyb.
Překvapivé. Tak tady by mě upřímně zajímaly odkazy na příslušné bug reporty.
Já jsem zase viděl filesystém, ze kterého jsem sice všechno bez problémů přečetl, ale scrub neproběhl bez chyb. To bylo proto, že odcházel harddisk a jedna z replik metadat už buď nešla přečíst vůbec, nebo na ní neseděly checksumy. (Že to postihlo zrovna kousek replikovaných metadat a nikoliv nereplikovaná data, to byla samozřejmě šťastná náhoda, nic jiného.) Opačný případ jsem ale zatím neviděl.
u starších polí bude na konciHistorky z roku 2010 nás nezajímají ;)
Je obdivuhodné, když někdo všechna svá mdadm pole poctivě kompletně reinicializuje pokaždé, když se změní formát metadat. Ano, s takovou důsledností se pak nemusíš zabývat historkami z roku 2010.
Jinak ta analogie nesedí, protože Btrfs byl v roce 2010 do značné míry experimentální, zatímco mdadm se považuje za stabilní zhruba od třetihor.
24.8.2017 08:54
Jendа | skóre: 78
| blog: Jenda
| JO70FB
NULA silent corruption.
Anekdoty mě příliš nezajímají. Podstatná jsou data. Slova o zaklínadlech prodejců jsou z oblasti konspiračních nesmyslů, nikoliv faktů. 190 TB a nějaké (předpokládám) jedno datové centrum je hodně malý vzorek na to, aby se z něj dalo cokoliv vyvozovat.
Především bych se jízlivě pousmál nad tím, že někdo počítá checksumy teprve až z toho, co mu filesystém vrací, nikoliv před zápisem těch dat, a myslí si, že tím něco "dokazuje". Když se data poškodí právě při zápisu, což je velmi pravděpodobné, pak se samozřejmě můžou tisíckrát "konzistentně" přečíst a všechno bude vypadat na jedničku.
Je překvapivé, na kolik hluboce zakořeněných pověr a iluzí o ukládání dat a o redundanci člověk narazí pokaždé, když zmíní prostý fakt, že RAID bez checksumů na úrovni filesystému je mnohem méně redundantní, než by se mohlo zdát.
Btrfs se nijak nechystá umřít a nikde není psáno, že to, na co je v RHEL nějaká komerční podpora, je v nějakém smyslu normou.
Kromě toho filesystém s checksumy není žádná závratná genialita; je to nezbytnost. Zda nakonec převládne Btrfs nebo jiný, novější a pokročilejší filesystém, to už je jiná otázka. Nicméně s neustálým růstem datových úložišť to bez checksumů nepůjde.
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
lsblk?
cat /proc/mdadm
24.8.2017 03:43
Jendа | skóre: 78
| blog: Jenda
| JO70FB
# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 149.1G 0 disk ├─sda1 8:1 0 9.3G 0 part │ └─md0 9:0 0 9.3G 0 raid1 / ├─sda2 8:2 0 3.7G 0 part [SWAP] └─sda3 8:3 0 136G 0 part sdb 8:16 0 149.1G 0 disk ├─sdb1 8:17 0 9.3G 0 part │ └─md0 9:0 0 9.3G 0 raid1 / ├─sdb2 8:18 0 3.7G 0 part [SWAP] └─sdb3 8:19 0 136G 0 part /btrfs sdc 8:32 0 153.4G 0 disk └─sdc1 8:33 0 137G 0 part sdd 8:48 0 153.4G 0 disk └─sdd1 8:49 0 137G 0 part #file /dev/sdc1 /dev/sdc1: block special (8/33) # file /dev/sdc /dev/sdc: block special (8/32)
#file -Ls /dev/sdc1 /dev/sdc1: BTRFS Filesystem sectorsize 4096, nodesize 16384, leafsize 16384, UUID=72c03b5f-3322-4d59-822f-55173a25f97c, 13280161792/586286104576 bytes used, 4 devices # file -Ls /dev/sdd1 /dev/sdd1: BTRFS Filesystem sectorsize 4096, nodesize 16384, leafsize 16384, UUID=72c03b5f-3322-4d59-822f-55173a25f97c, 13279657984/586286104576 bytes used, 4 devices # file -Ls /dev/sdd /dev/sdd: DOS/MBR boot sector; partition 1 : ID=0xee, start-CHS (0x0,0,1), end-CHS (0x3ff,254,63), startsector 1, 321672959 sectors, extended partition table (last) # file -Ls /dev/sdc /dev/sdc: DOS/MBR boot sector; partition 1 : ID=0xee, start-CHS (0x0,0,1), end-CHS (0x3ff,254,63), startsector 1, 321672959 sectors, extended partition table (last)
lsblk /dev/sdc1 -> not a block device lsblk /dev/sdd1 -> not a block device lsblk /dev/sdd name maj:min rm size ro type mountpoint sdd 8:32 0 153G 0 disk file -Ls /dev/sdd1 -> no such file or directory # file -Ls /dev/sdd /dev/sdd: DOS/MBR boot sector; partition 1 : ID=0xee, start-CHS (0x0,0,1), end-CHS (0x3ff,254,63), startsector 1, 321672959 sectors, extended partition table (last) # lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 149.1G 0 disk ├─sda1 8:1 0 9.3G 0 part │ └─md0 9:0 0 9.3G 0 raid1 / ├─sda2 8:2 0 3.7G 0 part [SWAP] └─sda3 8:3 0 136G 0 part sdb 8:16 0 149.1G 0 disk ├─sdb1 8:17 0 9.3G 0 part │ └─md0 9:0 0 9.3G 0 raid1 / ├─sdb2 8:18 0 3.7G 0 part [SWAP] └─sdb3 8:19 0 136G 0 part sdc 8:32 0 153.4G 0 disk sdd 8:48 0 153.4G 0 disk cat /proc/mdstat -> pouze raid md0 mount /dev/sda3 /btrfs BTRFS error (device sdb3): failed to read the system array: -5 BTRFS ERROR (device sdb3): open_ctree failed mount: wrong fs type, bad option...blablabla fdisk -l /dev/sdd /dev/sdd1 1(start) 326...(end) 321....(sectors) 153G(size) ee(id) gpt(type)Dost otazka, proc fdisk particii vidi a lsblk ne...
dmesg | grep ata2
[ +0,000003] ata2: SATA max UDMA/133 abar m2048@0xfb121000 port 0xfb121180 irq 26
[ +0,000496] ata2: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[ +0,012802] ata2.00: HPA detected: current 187547647, native 234441648
[ +0,001850] ata2.00: ATA-9: INTEL SSDSC2BW120A4, DC32, max UDMA/133
[ +0,000003] ata2.00: 187547647 sectors, multi 16: LBA48 NCQ (depth 31/32), AA
[ +0,011928] ata2.00: configured for UDMA/133
dulezity je, aby to sectors bylo UPLNE stejny na obou pocitacich
fdisk je chytry, ten se diva i na konec disku, kde je zalozni gpt, ale treba ta na zacatku chybi?
druha moznost je, ze na diskach je jakasi divna kombinace stareho mbr a noveho gpt?
bych asi disky prepsal nulama - jak zacatek, tak konec a udelal na ne mbr a pak znova nasypal data z partic pomoci dd
taky u tech GPT ten fdisk -l vypada presne jak? Ty pises start 1? To jsou bloky 512b? To by teda nemelo bejt, to ti udelal kdo? Schvalne se zacina az na 2048, nebo dokonce 8192, jestli toto neni ten problem?
taky je videt, ze jakoby ta partice neni pres cely disk, je tam jeste neco?
fdisk -l /dev/sdd Disk /dev/sdd: 153.4 GiB, 164696555520 bytes, 321672960 sectors [ 2.759481] sd 1:0:1:0: [sdd] 321672960 512-byte logical blocks: (165 GB/153 GiB)Dell:
fdisk -l /dev/sdd Disk /dev/sdd: 152.9 Gib, 164148281344 bytes, 320602112 sectors sd 0:2:3:0: [sdd] 320602112 512-byte logical blocks: (164 GB/ 153 GiB) gdisk: disk size smaller than the main header indicates ! Loading secondary header from the last sector of the disk ! Invalid backup GPT header, but valid main...............Na Dellu je ten disk z nejakeho duvodu mensi...btw, je tam Perc 6i radic.
fdisk /dev/sdd1 (start) 1 gdisk /dev/sdd1 (start) 2048
HP: /dev/sdd1 2048 287311871 287309824 137G Linux filesystem Dell: /dev/sdd1 1 321672959 321672959 153.4G ee GPTV obou pripadech ale je ten disk na Dellu videt mensi, resp. ten Dell zamenuje oddil za cely disk zrejme (minus chybejici kus).
HP: hdparm -N /dev/sdd: max sectors 321672960, HPA is disabled Dell: hdparm -N /dev/sdd: max sectors 0/1, HPA is enabled SG_IO bad/missing sense data, sb[]:ACHJO!! Pitomy Delly.
24.8.2017 04:13
Jendа | skóre: 78
| blog: Jenda
| JO70FB
(metodika: vyrobit 200MB FS, připojit, zapsat 19MB soubor, odpojit, truncatnout na 100 MB, připojit, zapsat malý soubor, sync, odpojit, připojit, soubor tam je a nikdo neřekl žádnou chybu, pustit scrub, pozorovat, jak počítač exploduje)
https://forums.freenas.org/index.php?threads/hardware-recommendations-read-this-first.23069/
If the controller you want to use is an Adaptec, Dell Perc, Highpoint, or some no-name brand you shouldn't even try to use them. All of these may or may not "work" but you'll find out later they don't properly handle SMART monitoring, SMART testing, passing of errors from the disk to the system, etc. Don't put your data at risk and go with *any* of these brands. You can thank us for saving your data later.
If you are using a Dell Perc and think that when we say "JBOD" we mean RAID0 of single disks, you are in error. JBOD is not the same as a RAID0 of a single disk, and you are making a grave error by thinking otherwise.
-----
Tiskni
Sdílej:
