Richard Stallman dnes v Liberci přednáší o svobodném softwaru a svobodě v digitální společnosti. Od 16:30 v aule budovy G na Technické univerzitě v Liberci. V anglickém jazyce s automaticky generovanými českými titulky. Vstup je zdarma i pro širokou veřejnost.
sudo-rs, tj. sudo a su přepsáné do programovacího jazyka Rust, nahradí v Ubuntu 25.10 klasické sudo. V plánu je také přechod od klasických coreutils k uutils coreutils napsaných v Rustu.
Fedora se stala oficiální distribucí WSL (Windows Subsystem for Linux).
Společnost IBM představila server IBM LinuxONE Emperor 5 poháněný procesorem IBM Telum II.
Byla vydána verze 4.0 multiplatformního integrovaného vývojového prostředí (IDE) pro rychlý vývoj aplikaci (RAD) ve Free Pascalu Lazarus (Wikipedie). Přehled novinek v poznámkách k vydání. Využíván je Free Pascal Compiler (FPC) 3.2.2.
Podpora Windows 10 končí 14. října 2025. Připravovaná kampaň Konec desítek (End of 10) může uživatelům pomoci s přechodem na Linux.
Již tuto středu proběhne 50. Virtuální Bastlírna, tedy dle římského číslování L. Bude L značit velikost, tedy více diskutujících než obvykle, či délku, neboť díky svátku lze diskutovat dlouho do noci? Bude i příští Virtuální Bastlírna virtuální nebo reálná? Nejen to se dozvíte, když dorazíte na diskuzní večer o elektronice, softwaru, ale technice obecně, který si můžete představit jako virtuální posezení u piva spojené s učenou
… více »Český statistický úřad rozšiřuje Statistický geoportál o Datový portál GIS s otevřenými geografickými daty. Ten umožňuje stahování datových sad podle potřeb uživatelů i jejich prohlížení v mapě a přináší nové možnosti v oblasti analýzy a využití statistických dat.
Kevin Lin zkouší využívat chytré brýle Mentra při hraní na piano. Vytváří aplikaci AugmentedChords, pomocí které si do brýlí posílá notový zápis (YouTube). Uvnitř brýlí běží AugmentOS (GitHub), tj. open source operační systém pro chytré brýle.
cat /proc/mdstat Personalities : [raid6] [raid5] [raid4] md0 : active raid5 sda1[0] sdh1[5] sdd1[3] sdc1[2] sdb1[1] 1845476736 blocks super 1.0 level 5, 32k chunk, algorithm 2 [5/5] [UUUUU] bitmap: 0/4 pages [0KB], 65536KB chunk unused devices: nonePo zcela nepochopitelné chybě: (z logu)
blk_update_request: I/O error, dev sdh, sector 112434432 bře 01 06:32:45 HQ-Server-NAS kernel: sd 8:0:0:0: [sdh] tag#28 CDB: Read(10) 28 00 06 b3 9d 00 00 00 b0 00 bře 01 06:32:45 HQ-Server-NAS kernel: sd 8:0:0:0: [sdh] tag#28 FAILED Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK bře 01 06:32:45 HQ-Server-NAS kernel: ata9: EH complete bře 01 06:32:45 HQ-Server-NAS kernel: ata9.00: disabled bře 01 06:32:45 HQ-Server-NAS kernel: ata9: reset failed, giving up bře 01 06:31:55 HQ-Server-NAS kernel: ata9: softreset failed (1st FIS failed) bře 01 06:31:45 HQ-Server-NAS kernel: ata9: hard resetting link bře 01 06:31:45 HQ-Server-NAS kernel: ata9.00: status: { DRDY } bře 01 06:31:45 HQ-Server-NAS kernel: ata9.00: cmd 60/b0:d0:00:9d:b3/00:00:06:00:00/40 tag 26 ncq 90112 in res 40/00:d0:00:9d:b3/00:00:06:00:00/40 Emask 0x10 (ATA bus error) bře 01 06:31:45 HQ-Server-NAS kernel: ata9.00: failed command: READ FPDMA QUEUED bře 01 06:31:45 HQ-Server-NAS kernel: ata9: SError: { UnrecovData 10B8B BadCRC } bře 01 06:31:45 HQ-Server-NAS kernel: ata9.00: irq_stat 0x08000000, interface fatal error bře 01 06:31:45 HQ-Server-NAS kernel: ata9.00: exception Emask 0x10 SAct 0x4000000 SErr 0x280100 action 0x6 frozenNásledované (z logu)
md/raid:md0: Disk failure on sdh1, disabling device. md/raid:md0: Operation continuing on 4 devices.Byly soubory přístupné, ale některé obsahovaly blbosti. Disk jsem připojil na jiný port řadiče a zatím funguje OK (pole je sestavené a po doplnění disku do pole (re-add) jsou soubory v pořádku). Dal jsem se do pátrání co je špatně, protože RAID 5 by měl poskytovat OK data i za předpokladu výpadku jednoho disku. Na funkčním poli jsem: odpojil pole, ručně nastavil:
mdadm --manage /dev/md0 --fail /dev/sdh1a pole opět sestavil (s 4-mi z 5-ti disků). Překvapivě data jsou stejně špatně jako předtím. Po zpětném připojení disku (re-add) jsou data zase OK. Otázka zní: Co dělám špatně, že jsou data poničená, když jeden disk chybí? Je tohle normální chování raid5? Pro jistotu ještě:
mdadm --examine /dev/sdh1 /dev/sdh1: Magic : a92b4efc Version : 1.0 Feature Map : 0x1 Array UUID : f7090e9b:234dc67a:95fe16d6:99663094 Name : any:0 Creation Time : Mon Feb 29 19:55:03 2016 Raid Level : raid5 Raid Devices : 5 Avail Dev Size : 922738408 (440.00 GiB 472.44 GB) Array Size : 1845476736 (1759.98 GiB 1889.77 GB) Used Dev Size : 922738368 (440.00 GiB 472.44 GB) Super Offset : 922738672 sectors Unused Space : before=0 sectors, after=288 sectors State : clean Device UUID : 0a1ca6f6:783ade5e:b7e65361:16059866 Internal Bitmap : -16 sectors from superblock Update Time : Tue Mar 1 08:14:57 2016 Bad Block Log : 512 entries available at offset -8 sectors Checksum : d3ae3f40 - correct Events : 3974 Layout : left-symmetric Chunk Size : 32K Device Role : Active device 4 Array State : AAAAA ('A' == active, '.' == missing, 'R' == replacing)Děkuji za reakce
Řešení dotazu:
Personalities : [raid6] [raid5] [raid4] md0 : active raid5 sdc1[2] sdb1[1] sdh1[5] sda1[0] sdd1[3] 1845476736 blocks super 1.0 level 5, 32k chunk, algorithm 2 [5/5] [UUUUU] [>....................] check = 0.1% (801920/461369184) finish=38.2min speed=200480K/sec bitmap: 2/4 pages [8KB], 65536KB chunk unused devices: noneMyslíte, že to není synchronizovaný? (vypadá to tak) Jak je to možné? Večer jsem sestavil pole, počkal až se dokončí sync a nahrál data. Pak několikrát pole zastavil a spustil, přidelil práva souborům.... Nechápu proč to není synchronizovaný?
check
udělat repair
).
A podezříval bych vadnou RAM.
mdadm --create --bitmap=internal --metadata=1.2 --level=5 --chunk=32 --raid-devices=5 /dev/md0 /dev/sda1 /dev/sdb1 /dev/sdc1 /dev/sdd1 /dev/sdh1Po dokončení synchnizace: (pole zatím není zformátované) a pokusu o kontrolu
echo check > /sys/block/md0/md/sync_action
cat /sys/block/md0/md/mismatch_cntuž mám po 11% kontroly 106134272 chyb. Já už fakt nevím, co dělám špatně! Prosím poraďte
ata9.00: status: { DRDY } bře 01 14:35:58 HQ-Server-NAS kernel: ata9.00: cmd 60/08:88:70:21:31/04:00:08:00:00/40 tag 17 ncq 528384 in res 40/00:68:f8:0f:31/00:00:08:00:00/40 Emask 0x10 (ATA bus error) bře 01 14:35:58 HQ-Server-NAS kernel: ata9.00: failed command: READ FPDMA QUEUED bře 01 14:35:58 HQ-Server-NAS kernel: ata9.00: status: { DRDY } bře 01 14:35:58 HQ-Server-NAS kernel: ata9.00: cmd 60/40:80:30:1c:31/05:00:08:00:00/40 tag 16 ncq 688128 in res 40/00:68:f8:0f:31/00:00:08:00:00/40 Emask 0x10 (ATA bus error) bře 01 14:35:58 HQ-Server-NAS kernel: ata9.00: failed command: READ FPDMA QUEUED bře 01 14:35:58 HQ-Server-NAS kernel: ata9.00: status: { DRDY } bře 01 14:35:58 HQ-Server-NAS kernel: ata9.00: cmd 60/40:78:f0:16:31/05:00:08:00:00/40 tag 15 ncq 688128 in res 40/00:68:f8:0f:31/00:00:08:00:00/40 Emask 0x10 (ATA bus error) bře 01 14:35:58 HQ-Server-NAS kernel: ata9.00: failed command: READ FPDMA QUEUED bře 01 14:35:58 HQ-Server-NAS kernel: ata9.00: status: { DRDY } bře 01 14:35:58 HQ-Server-NAS kernel: ata9.00: cmd 60/40:70:b0:11:31/05:00:08:00:00/40 tag 14 ncq 688128 in res 40/00:68:f8:0f:31/00:00:08:00:00/40 Emask 0x10 (ATA bus error) bře 01 14:35:58 HQ-Server-NAS kernel: ata9.00: failed command: READ FPDMA QUEUED bře 01 14:35:58 HQ-Server-NAS kernel: ata9.00: status: { DRDY } bře 01 14:35:58 HQ-Server-NAS kernel: ata9.00: cmd 60/b8:68:f8:0f:31/01:00:08:00:00/40 tag 13 ncq 225280 in res 40/00:68:f8:0f:31/00:00:08:00:00/40 Emask 0x10 (ATA bus error) bře 01 14:35:58 HQ-Server-NAS kernel: ata9.00: failed command: READ FPDMA QUEUED bře 01 14:35:58 HQ-Server-NAS kernel: ata9.00: status: { DRDY } bře 01 14:35:58 HQ-Server-NAS kernel: ata9.00: cmd 60/40:60:b8:0a:31/05:00:08:00:00/40 tag 12 ncq 688128 in res 40/00:68:f8:0f:31/00:00:08:00:00/40 Emask 0x10 (ATA bus error) bře 01 14:35:58 HQ-Server-NAS kernel: ata9.00: failed command: READ FPDMA QUEUED bře 01 14:35:58 HQ-Server-NAS kernel: ata9.00: status: { DRDY } bře 01 14:35:58 HQ-Server-NAS kernel: ata9.00: cmd 60/40:58:78:05:31/05:00:08:00:00/40 tag 11 ncq 688128 in res 40/00:68:f8:0f:31/00:00:08:00:00/40 Emask 0x10 (ATA bus error) bře 01 14:35:58 HQ-Server-NAS kernel: ata9.00: failed command: READ FPDMA QUEUED bře 01 14:35:58 HQ-Server-NAS kernel: ata9.00: status: { DRDY } bře 01 14:35:58 HQ-Server-NAS kernel: ata9.00: cmd 60/40:50:38:00:31/05:00:08:00:00/40 tag 10 ncq 688128 in res 40/00:68:f8:0f:31/00:00:08:00:00/40 Emask 0x10 (ATA bus error) bře 01 14:35:58 HQ-Server-NAS kernel: ata9.00: failed command: READ FPDMA QUEUED bře 01 14:35:58 HQ-Server-NAS kernel: ata9: SError: { UnrecovData 10B8B BadCRC } bře 01 14:35:58 HQ-Server-NAS kernel: ata9.00: irq_stat 0x08000008, interface fatal error bře 01 14:35:58 HQ-Server-NAS kernel: ata9.00: exception Emask 0x10 SAct 0x3fc00 SErr 0x280100 action 0x6 frozenJdu bádat dále :(
memtester 15000 1 memtester version 4.3.0 (64-bit) Copyright (C) 2001-2012 Charles Cazabon. Licensed under the GNU General Public License version 2 (only). pagesize is 4096 pagesizemask is 0xfffffffffffff000 want 15000MB (15728640000 bytes) got 15000MB (15728640000 bytes), trying mlock ...locked. Loop 1/1: Stuck Address : ok Random Value : ok Compare XOR : ok Compare SUB : ok Compare MUL : ok Compare DIV : ok Compare OR : ok Compare AND : ok Sequential Increment: ok Solid Bits : ok Block Sequential : ok Checkerboard : ok Bit Spread : ok Bit Flip : ok Walking Ones : ok Walking Zeroes : ok 8-bit Writes : ok 16-bit Writes : ok Done.Jdu laborovat disk/řadič
Jediný smysluplný zlepšovák je mkfs.btrfs
. To ostatní mi přijde jako zoufalá ztráta času.
Funguje to aj bez ECC pamäte ?
A přesně tohle RAID dělá.O nic víc než ne-RAID použití. Uveď příklad (nejlépe i pro RAID1).
smartctl 6.2 2013-11-07 r3856 [x86_64-linux-4.1.15-8-default] (SUSE RPM) Copyright (C) 2002-13, Bruce Allen, Christian Franke, www.smartmontools.org === START OF INFORMATION SECTION === Device Model: OCZ-VECTOR180 Serial Number: XXXXXXXXXXXXXXXXXX LU WWN Device Id: 5 e83a97 100050c8b Firmware Version: 1.01 User Capacity: 480 103 981 056 bytes [480 GB] Sector Size: 512 bytes logical/physical Rotation Rate: Solid State Device Device is: Not in smartctl database [for details use: -P showall] ATA Version is: ATA8-ACS (minor revision not indicated) SATA Version is: SATA 3.1, 6.0 Gb/s (current: 3.0 Gb/s) Local Time is: Thu Mar 3 10:37:57 2016 CET SMART support is: Available - device has SMART capability. SMART support is: Enabled === START OF READ SMART DATA SECTION === SMART overall-health self-assessment test result: PASSED General SMART Values: Offline data collection status: (0x00) Offline data collection activity was never started. Auto Offline Data Collection: Disabled. Self-test execution status: ( 0) The previous self-test routine completed without error or no self-test has ever been run. Total time to complete Offline data collection: ( 0) seconds. Offline data collection capabilities: (0x1d) SMART execute Offline immediate. No Auto Offline data collection support. Abort Offline collection upon new command. Offline surface scan supported. Self-test supported. No Conveyance Self-test supported. No Selective Self-test supported. SMART capabilities: (0x0003) Saves SMART data before entering power-saving mode. Supports SMART auto save timer. Error logging capability: (0x00) Error logging NOT supported. General Purpose Logging supported. Short self-test routine recommended polling time: ( 0) minutes. Extended self-test routine recommended polling time: ( 0) minutes. SMART Attributes Data Structure revision number: 18 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 5 Reallocated_Sector_Ct 0x0000 000 000 000 Old_age Offline - 0 9 Power_On_Hours 0x0000 100 100 000 Old_age Offline - 4733 12 Power_Cycle_Count 0x0000 100 100 000 Old_age Offline - 78 171 Unknown_Attribute 0x0000 100 100 000 Old_age Offline - 162138448 174 Unknown_Attribute 0x0000 100 100 000 Old_age Offline - 5 190 Airflow_Temperature_Cel 0x0000 100 100 000 Old_age Offline - 24 195 Hardware_ECC_Recovered 0x0000 100 100 000 Old_age Offline - 0 196 Reallocated_Event_Count 0x0000 100 100 000 Old_age Offline - 0 197 Current_Pending_Sector 0x0000 100 100 000 Old_age Offline - 0 208 Unknown_SSD_Attribute 0x0000 100 100 000 Old_age Offline - 3 210 Unknown_Attribute 0x0000 100 100 000 Old_age Offline - 0 224 Unknown_SSD_Attribute 0x0000 100 100 000 Old_age Offline - 1 225 Unknown_SSD_Attribute 0x0000 100 100 000 Old_age Offline - 0 226 Unknown_SSD_Attribute 0x0000 100 100 000 Old_age Offline - 0 233 Media_Wearout_Indicator 0x0000 100 100 000 Old_age Offline - 100 241 Total_LBAs_Written 0x0000 100 100 000 Old_age Offline - 1212 242 Total_LBAs_Read 0x0000 100 100 000 Old_age Offline - 8024 249 Unknown_Attribute 0x0000 100 100 000 Old_age Offline - 42098548 SMART Error Log Version: 1 No Errors Logged Warning! SMART Self-Test Log Structure error: invalid SMART checksum. SMART Self-test log structure revision number 1 No self-tests have been logged. [To run self-tests, use: smartctl -t] Selective Self-tests/Logging not supported
Co dělám špatně, že jsou data poničená, když jeden disk chybí?
Všechno špatně. RAID funguje jedině tehdy, ví-li o něm filesystém a je-li integrovaný do filesystému. Tedy Btrfs nebo ZFS dávají smysl jako RAID. Ten RAID, o kterém filesystém neví, je náchylný k silent data corruption, což je přesně tato situace.
Problém je, že softwarový (ba i hardwarový, to je úplně jedno) RAID 5, který není integrovaný ve filesystému, splní svůj účel jedině tehdy, pokud disky selhávají stylem všechno nebo nic. Předpokládá se tedy, že disk buď vrací 100% správná data a nedělá nikde chyby, nebo okamžitě a úplně selže, aniž by kdy vrátil špatná data. Takový předpoklad je od praxe na hony vzdálený.
Kdyby tam byl Btrfs RAID 5 nebo ZFS RAIDZ, tohle by se nikdy nestalo díky automatickým checksumům, které filesystém používá. Pro příklad uvažme, jak se z RAIDu 5 čte. Máme-li pole s N disky, pak k přečtení dat stačí 4 disky a na pátém je paritní součet (ať už xor nebo něco sofistikovanějšího). Parita je distribuovaná, tedy každý RAID blok má paritní součet na jiném z disků, aby v RAIDu nebyl jeden přetížený paritní disk. Když je třeba přečíst data, stačí k tomu pouze N - 1 z N disků. Nikdo při čtení automaticky nekontroluje paritu na tom N-tém disku, jestli opravdu sedí — kvůli efektivitě, samozřejmě. Mnohem dalekosáhlejší důsledky z hlediska efektivity má v tomto směru třeba prokládané čtení z několika disků u RAID 1. Ale to už odbočuju. U RAID 5 s N disky je zkrátka potřeba N - 1 operací k přečtení toho, co se zapisovalo N operacemi.
U hardwarového nebo softwarového RAIDu 5 bez podpory ve filesystému se v případě poškození dat na discích přečtou a vrátí špatná data a nikdo problém neodhalí. Selže-li následně jeden z disků, teprve tehdy se při čtení použije parita. Byla-li původní data špatná, rekonstrukce pomocí parity vrátí zase špatná data, ať už je parita samotná zachovaná správně nebo špatně. Není proti tomu žádná účinná prevence!
RAID 1 bez podpory ve filesystému má tentýž problém. Při prokládaném čtení nezjišťuje, jestli se repliky shodují, a i kdyby se neshodovaly, bez checksumů nemá absolutně žádnou možnost zjistit, která z replik mluví pravdu.
RAID 5 v Btrfs nebo RAIDZ v ZFS naopak tohle všechno ustojí bez problémů. Dejme tomu, že při čtení z pole u jednoho disku nesedí checksum pro nějaký stripe. Pak filesystém zaprvé hned ví, na kterém disku jsou pro daný RAID blok špatná data, a zadruhé ví, že musí mimořádně pro tento blok přečíst také paritu (samozřejmě rovněž chráněnou checksumem!) a dopočíst správná data z parity a z N - 2 ostatních zdravých stripů. Navíc je namístě rovnou opravit stripe na tom disku, kde neseděl checksum, aby se pro celý RAID blok zase obnovila plná redundance.
Pro RAID 1 v Btrfs nebo ZFS platí totéž. Čte se prokládaně jako všude jinde a dokud checksumy sedí, je to v pořádku. Jakmile checksum nesedí, načte se daný blok z jiné repliky — z takové, kde checksum sedí — a následně se obnoví pořádek. Opět přímo filesystém ví, která replika selhává a odkud je možné ji obnovit.
Je tohle normální chování raid5?
Ano, je. RAID 5 bez podpory ve filesystému nedává smysl. Je náchylný přesně k těmto chybám, zejména když je na něm navíc ještě nějaký filesystém z minulého desetiletí, který nejen neumí RAID, ale dokonce zjevně ani nedělá checksumy dat. (Hrůza pomyslet!)
Postupem doby pravděpodobnost okamžitého totálního selhání celého disku klesá, zatímco pravděpodobnost silent data corruption roste. To druhé má taky souvislost s rostoucí kapacitou disků. RAID 5 bez podpory ve filesystému nechrání data před poškozením. Některá fakta se člověk naučí the hard way — tak už to v životě chodí.
<off_topic>
Už se těším, až mi jednou zase některý slavný místní žvanil bude tvrdit, že silent data corruption v praxi neexistuje a že disky selhávají jedině jako celek. Skvělou odpovědí pak bude odkaz na tento dotaz. (Ne že by se na webu neválelo hned několik barvitých popisů dalších podobných incidentů.)
</off_topic>
Tu je skôr problém, že SSD nižšiej kvality nie je vhodný.
Je už Btrfs v použitelném stavu?Není. Jsou tam podivné bugy a nedotaženosti. Např.
Mountnutí středně velkého (6TB) svazku trvá minutu.
Vzpomínám na dobu, kdy boot nějakého serveru trval 40 minut a všichni si to považovali, protože to byla známka opravdu velkého serveru. Potom jsem testoval nějaký fs (už nevím, to bylo v době, kdy i ext3 byla těžká novinka) a velký disk se poznal tak, že ho to připojovalo 5 minut. Dneska je to bug
Jinak mě se btrfs 10TB připojuje (připojuju jednak root subvolume a potom několik (asi 8) subvolume a celé to trvá asi jen 20s. A to asi zejména proto, že to systemd připojuje všechno naráz, takže to trochu víc seekuje, než by bylo zdrávo. To tam je několik tisíc snapshotů a několik miliónů souborů (nepočítaje ty v těch snapech).
Zdá se, že to furt autodefraguje, i když je vypnutý autodefrag. Prostě to *furt* hrabe na disk.
I kdyby, tak na tom je špatně co (teda kromě toho, že by to nerespektovalo nastavení)?
Má to implementovanou kompresi, ale nikdo neimplementoval dekompresi. Je o tom malinká poznámka v dokumentaci, které jsem si nevšiml.
To jako že když data jednou zakomprimuješ, tak jsi o ně přišel? Nezdá se. Prosím o odkaz.
I kdyby, tak na tom je špatně co (teda kromě toho, že by to nerespektovalo nastavení)?Že mám pod tím pole (ano, nepoužívám to vestavěné v btrfs, protože když jsem ten stroj instaloval, byl integrovaný RAID5 poněkud experimentální), a když se rebuilduje, nebo se kontroluje konzistence, tak to pro samé seekování jede strašně pomalu.
To jako že když data jednou zakomprimuješ, tak jsi o ně přišel? Nezdá se. Prosím o odkaz.Ne, že balance/defrag umí zkonvertovat existující svazek jako kdyby byl od začátku připojený s volbou compress, ale naopak to neumí. (nic kritického, spíš to ukazuje nedoladěnost)
Ne, že balance/defrag umí zkonvertovat existující svazek jako kdyby byl od začátku připojený s volbou compress, ale naopak to neumí. (nic kritického, spíš to ukazuje nedoladěnost)
Na to by mělo stačit ten svazek připojit jako nocompress a pustit na to balance. Nebo jsem něco přehlíd?
Už se těším, až mi jednou zase některý slavný místní žvanil bude tvrdit, že silent data corruption v praxi neexistujeJak víš, že v tomto dotazu jde o silent data corruption?
Tiskni
Sdílej: