Byla vydána nová stabilní verze 3.5 svobodného multiplatformního softwaru pro editování a nahrávání zvukových souborů Audacity (Wikipedie). Přehled novinek také na YouTube. Nově lze využívat cloud (audio.com). Ke stažení je oficiální AppImage. Zatím starší verze Audacity lze instalovat také z Flathubu a Snapcraftu.
50 let operačního systému CP/M, článek na webu Computer History Museum věnovaný operačnímu systému CP/M. Gary Kildall z Digital Research jej vytvořil v roce 1974.
Byl zveřejněn program a spuštěna registrace na letošní konferenci Prague PostgreSQL Developer Day, která se koná 4. a 5. června. Na programu jsou 4 workshopy a 8 přednášek na různá témata o PostgreSQL, od konfigurace a zálohování po využití pro AI a vector search. Stejně jako v předchozích letech se konference koná v prostorách FIT ČVUT v Praze.
Po 48 letech Zilog končí s výrobou 8bitového mikroprocesoru Zilog Z80 (Z84C00 Z80). Mikroprocesor byl uveden na trh v červenci 1976. Poslední objednávky jsou přijímány do 14. června [pdf].
Ještě letos vyjde Kingdom Come: Deliverance II (YouTube), pokračování počítačové hry Kingdom Come: Deliverance (Wikipedie, ProtonDB Gold).
Thunderbird 128, příští major verze naplánovaná na červenec, přijde s nativní podporou Exchange napsanou v Rustu.
Byly vyhlášeny výsledky letošní volby vedoucího projektu Debian (DPL, Wikipedie). Novým vedoucím je Andreas Tille.
Po osmi měsících vývoje byla vydána nová verze 0.12.0 programovacího jazyka Zig (GitHub, Wikipedie). Přispělo 268 vývojářů. Přehled novinek v poznámkách k vydání.
Poslední měsíc byl plný zajímavých akcí, o kterých Vám bastlíři z projektu MacGyver mohou povědět, protože se na ně sami vydali. Kde všude byli, ptáte se? Objevili se na Installfestu, Arduino Day, Hackaday Europe a tajném srazu bastlířů z Twitteru. A z každé akce pro vás mají zajímavé poznatky.
… více »Mezinárodní nezisková organizace Women Who Code (WWCode, Wikipedie) založena v roce 2011 s cílem usnadnit ženám vstup do světa informačních technologií nečekaně skončila. Došly finance.
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
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: none
Po 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 frozen
Ná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: none
Myslí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ý?
1.3.2016 10:59
Jendа | skóre: 78
| blog: Jenda
| JO70FB
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 frozen
Jdu 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 ?
4.3.2016 19:26
Jendа | skóre: 78
| blog: Jenda
| JO70FB
A přesně tohle RAID dělá.O nic víc než ne-RAID použití. Uveď příklad (nejlépe i pro RAID1).
Máš pravdu spíše jsem měl napsat tazatelův RAID. Protože RAID 1 rozklad po discích samozřejmě nedělá. Ale tazatel měl RAID 5 na 5 discích a tím sníží velikost zapisované struktury do jednoho disku 4x.
Zkus si představit, co bys musel jako programátor dělat, když máš strukturu, kde je Read block 512 B, write block 16 kB a delete block 512 kB. S tím, že číst můžeš jak chceš. Zapsat ten 16 kB block můžeš jen do prázdného místa, Takže když z toho 16kB místa bloku obsadíš jen 512B nebo 1kB nemůžeš zapsat další 1kB do toho samého, musíš přečíst 1kB bloku, co je a zapsat 16kB (s obsazenými 2kB) jinam. A když potřebuješ někam zapsat a nemáš kam, tak jediné, co můžeš je smazat 512kB blok (a mimochodem to smazání trvá neco mezi 100-150 ms což je strašně dlouho). A celé se to má logicky tvářit jako blokové zařízení o velikosti bloku 512B s tím, s žádným rozlílem s prací s bloky. A teď jde o to kolik elektroniky nasázíš okolo, aby jsi přístup k chipům zparalelizoval (jinak máš rychlost jak na pomalých kartách) kolik a jak velkých máš buffery aby jsi jednak zápis odchytil ve vyšší rychlosti než píšeš do chipů, a když už má paralelizaci takovou, že bys zápis stihl tak buffery na to aby jsi požadavky združil a skutečně zapisoval po jednotlivých write blocích. A dále elektroniku, aby jsi byl schopen bloky uklízet, tedy u těch mazací bloky, které jsou z části už namarkované jako volné/neobsazené přečíst zbylá data, zapsat jinam a celý blok smazat. USB flasky to velmi často nedělají samy od sebe vůbec a consumer disky mnohdy potřebují nějakou dobu "nečinnosti", aby se pustily do úklidu, enterprise uklízí i při zátěži.
Osobně si myslím, že je problém, že disky nemají ani option, kdy by hlásily skutečné své parametry (velikosti jednotlivých bloků a ke každému mazacímu bloku jeho vnitřní podstrukturu v write blocích a obsazenost) a řízení takové nestejnoměrné blokové struktury by mělo být součásti FS. Podobně jako tady Andrej opakovaně píše, že RAID by měl být součástí FS jako má ZFS a BTRFS, protože volby jak vytvářet redundanci by měly být se znalostí dat, které se rozprostírají, si myslím, že organizace, co zapisovat do jakých mazacích bloků by mělo být součástí FS. Ano znamenalo by to návrh zcela nového FS a asi dost výzkumu. Ale také si myslím, že dokud Microsoft, neřekne chceme vyvinout zcela nový FS pro SSD disky, pošlete ven informace, co se skutečně v disku děje, nic se nezmění.
5.3.2016 19:49
vandrovnik | skóre: 21
3.3.2016 20:55
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
Takze u mne je dany kus/serie zmetek (slabe nebo zadne crc?). Pokud ovsem neni zrada v necem jinem. (kable, radic...)
Zrovna smart si kazdy vyrobce hlasi jak mu napadne 
V jedne masine mi bezi 64GB Transcend (jeste IDE)... a ten priznava asi 5 hodnot. 
... a trim taky neumi. Zatim zije.
5.3.2016 21:15
vandrovnik | skóre: 21
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ý.
4.3.2016 15:45
Jendа | skóre: 78
| blog: Jenda
| JO70FB
Je už Btrfs v použitelném stavu?Není. Jsou tam podivné bugy a nedotaženosti. Např.
4.3.2016 16:10
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
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.
4.3.2016 18:09
Jendа | skóre: 78
| blog: Jenda
| JO70FB
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)
4.3.2016 18:48
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
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?
4.3.2016 19:29
Jendа | skóre: 78
| blog: Jenda
| JO70FB
4.3.2016 16:00
Jendа | skóre: 78
| blog: Jenda
| JO70FB
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?
6.3.2016 08:20
pavlix | skóre: 54
| blog: pavlix
Tiskni
Sdílej:
