Portál AbcLinuxu, 3. května 2025 16:26
Bolí mě už několik dní dost nepříjemně v krku – druhotný následek chřipečky minulého týdne, ale podle doktorky jsem zdráv, protože nesípu, nekašlu, teplotu nemám, na mandích nic vidět není, CRP je nízké a test na streptokoka je negativní. Ale když jsem poněkud svižněji přeběhnul včera do vedlejší budovy, měl jsem pocit že pojdu. Tak jsem dnes radši zůstal doma, abych se trochu zotavil.
V návalu zoufalství, jsem včera večer ještě cinknul kamarádce – lékařce. Protože medikament, který mi byl předepsán je v celé Praze k nesehnání a navíc bez alternativy. A ta mi poslala erecept na nějaký kortikoidový prášek, po kterém se to zdá být mírně lepší, tak uvidíme.
Po zapnutí kompu mne dnes ráno čekalo překvapení.
Nějaký dobrák se zřejmě rozhodl využít díry v blíže nespecifikovaném zařízení, distribuovaném v Německu (nebo nodů k toru) k tomu, aby jejich prostřednictvím zaútočil na můj štvavý server, protože od 6:00 cca co 5 minut banoval nějakou IP adresu, ze které kdosi pokoušel nabourat jeho databázi. Šlo převážně o německé IP adresy a zajímavé je, že to po IPv4 zkoušel cca první půl hodinu a už zkoušel výhradně IPv6.
Jenže má smůlu, filtr, který používá fail2ban jen tak neošálí. Je můj vlastní a zařezává útočníky na základě toho co se snaží použít v URL – a komplet. Takže až vypráská svůj seznam nodů, bude po útoku...
No, tak jich během 6 hodin, než jsem se dostal k tomu abych tohle dopsal zablokoval 141. Seznam uvedu, jen pro zájemce z závěru.
Čas od času se tu najde někdo pohoršený tím, že považuji některé osoby hanící Btrfs za debilní. Ale mohou si za to samy. Jako kupř. v tomto případě:
Planuju na starych rotacnich discich WD (asi jsou tam 4 - 10 TB) udelat 2 particie po par TB, kazdou na jinem disku a na ne dat neco jako btrfs raid1. … Nevyznam se v btrfs, tak budu vdecny za nasmerovani a opravy. S vysledky se rad podelim.
To jako čeká, že mu ty disky Btrfs nějakým zázrakem vyléčí, nebo co?
S WD disky mám jen ty nejhorší zkušenosti a rotační disk má jen tu výhodu, že mu sektory neumírají naráz, jinak je pomalý až hrůza a čím větší je, tím déle trvá než se z něj nějaká data vydolují.
Mne na tom nepopouzí ten plán sám o sobě, ale to že dotyčný pak bude ve zdejších diskuzích plivat na Btrfs, jen proto, že mu veškeré problémy s ním spojené bude okamžitě hlásit.
A protože náhoda tomu chtěla, zrovna včera jsme narazili na ukázkový příklad nedomyšlené aplikace Btrfs u Synology.
Je zastaralé řešení, které jsem kdysi dávno také používal, takže vím moc dobře kde má své slabiny.
Veškerá péče o integritu dat je na bedrech MD raidu, který ale neví nic o datech, která jsou nad ním, protože pracuje na úrovni blokového zařízení. Jednička, nula, všecko jedno. Jeho úkolem je udržovat integritu na úrovni blokového zařízení, takže stripuje i neuklizený bordel bez užitné hodnoty a mrhá výpočetním výkonem.
Svého času, v dobách kdy rotační disky umíraly postupně, to bylo rozumné řešení protože je i v případě nekonzistence po nějakém čase schopen dát všechna data dohromady.
Ovšem opravdový kopec srandy nastal, když z nějakého důvodu umřelo celé zařízení.
Pouze jednou v životě jsem šel do modulárního zdroje a o zmíněnou legraci se spolehlivě staraly jeho kabely, než jsem ho vyměnil. Stačil jenom malý otřes skříně, když jsi strčil ho hot-swapového bloku jiný disk a některé z napájecí větvi kleslo napájení, nebo chytla špatný kontakt.
Důsledkem bylo že vypadnul jeden až dva disky a celé pole bylo nutné rekonstruovat. Trvalo to 9 hodin než se to MD raid6 pole tvořené čtyřmi 2TB disky zesynchronizovalo. A pokud se ten problém během toho syncu zopakoval, tak to znamenalo dalších 9 hodin křečí v oblasti kolem žaludku.
Proto jsem se důsledně vyhýbal veškeré činnosti, která by to nějakým způsobem prodloužila. Nejrychleji tahle operace proběhne, když se to pole nepoužívá. Proto je pořadí toho co se má udělat jasně dané:
Ale Btrfs není Ext4. Nepotřebuje žádný fsck, protože funguje jinak. Je to COW systém. Zapisuje data jen tam, kam se dají zapsat. A zapsané nepřepisuje. Jeho úkolem je vrátit obsah, který se po zpracování zapíše na jiné místo a ten původní blok se jen označí jako volný prostor. Tím vzniká na blokovém zařízení datový bordel, ovšem pokud je to fyzické zařízení, je to fuk. Při zápisu je úplně jedno, jestli se přepisuje nula nebo jednička. A pokud je v multidevice módu stará se jen o to, aby kopie validního datového bloku nebyly na stejném zařízení.
Proto jsem také přešel na Btrfs multidevice mód raid1. Odpadlo to nekonečné čekání na konec synchronizace. Pole bylo možné ihned po oživení odpadlé napájecí větve a restartu namountovat a scrub běžící na pozadí postupně kontroluje, jsou-li všechna data tam co mají být.
Btrfs v single-modu nad MD raidem, je vždy výhodnější než Ext4, ale nemá šanci něco vyřešit v případě, že se něco děje s některým diskem. A pokud ho připojíte dřív než MD raid skončí synchronizaci, akorát to pohnojíte.
U MD raidu, když vypadne nebo selže blokové zařízení je potřeba přidat nové a udělat synchonizaci. I když je to ten samý disk a nezmění se ani bit, protože MD raid (na rozdíl od FS) neví, co je bordel a co ne. Musí to udělat od začátku do konce a když to připojíte a začnete něco na to pole zapisovat, hodně se to zpomalí. A když paralelně běží také scrub, jde o zpomalení brutální.
Proč?
Scrub kontroluje zapsaná data a pokud požadovaný datový blok ještě není MD raidem zpracovaný, musí počkat až ho zpracuje. Teprve pak potřebná data dostane, aby mohl ověřit jejich kontrolní součet. A když mezi tím zapíšete další data, zpomalí se to ještě víc, protože MD raid nedovolí zapsat nový datový blok do míst, která ještě nemá pod kontrolou.
A problém zmíněného Synology je že přesně tuhle nešťastnou kombinaci umožňuje, což vede k jeho brutálnímu zpomalení, aniž by uživatel, který má sdílený adresář připojený odjinud, tušil co za tím je. A do toho ještě posílá poplašné zprávy co mu vrací scrub.
Pokud by se chtěl někdo bavit zkoumáním těch IP adres, co se pokoušely dnes nabouchat tu moji, doporučuji server https://www.abuseipdb.com, protože tam jsou hlášeny také incidenty z těchto adres, co napráskali jiní. A můžete si otestovat i vlastní zařízení, jestli náhodou nebylo v minulosti někým zneužité:
107.189.3.94 109.70.100.6 114.119.128.0_19 130.193.15.79 149.102.251.9 171.25.193.77 185.220.100.242 185.220.100.250 185.220.101.67 185.220.101.77 185.227.68.78 185.246.188.74 185.253.162.143 185.253.97.238 185.39.207.83 185.40.4.38 192.210.214.10 192.42.116.191 192.42.116.192 192.42.116.197 192.42.116.198 192.42.116.209 192.42.116.210 192.42.116.211 194.32.122.21 2a0b:f4c0:16c:6::1 2a0b:f4c2:: 2a0b:f4c2::1 2a0b:f4c2:1::1 2a0b:f4c2::14 2a0b:f4c2::15 2a0b:f4c2::18 2a0b:f4c2::23 2a0b:f4c2::27 2a0b:f4c2::28 2a0b:f4c2::29 2a0b:f4c2::3 2a0b:f4c2::31 2a0b:f4c2:3::64 2a0b:f4c2:3::67 2a0b:f4c2:3::69 2a0b:f4c2:3::72 2a0b:f4c2:3::75 2a0b:f4c2:3::83 2a0b:f4c2:3::86 2a0b:f4c2::4 2a0b:f4c2:4::101 2a0b:f4c2:4::103 2a0b:f4c2:4::104 2a0b:f4c2:4::110 2a0b:f4c2::6 2a0b:f4c2::9 2a0c:5700:3133:1705:be24:11ff:fe0f:9e53 2a0c:5700:3133:1705:be24:11ff:fe37:3cb 2a0c:5700:3133:1705:be24:11ff:fe58:9714 2a0c:5700:3133:4000:be24:11ff:fe07:68d 2a0c:5700:3133:4000:be24:11ff:fe3c:6727 2a0d:bbc7:0:1::1df 2a0d:bbc7:0:1::10a 2a0d:bbc7:0:1::2ef 2a0d:bbc7:0:1::3bd 2a0d:bbc7:0:1::3cc 2a0d:bbc7:0:1::3d5 2a0d:bbc7:0:1::328 2a0d:bbc7:0:1::38c 2a0d:bbc7:0:1::394 2a0e:e701:1198::1 2a0e:4005:1002:ffff:185:40:4:127 2a0e:4005:1002:ffff:185:40:4:132 2a0e:4005:1002:ffff:185:40:4:149 2a0e:4005:1002:ffff:185:40:4:29 2a0e:4005:1002:ffff:185:40:4:64 2a0f:df00:0:255::200 2a0f:df00:0:255::203 2a0f:df00:0:255::206 2a00:1b88:4::4 2a00:16b0:1:243::7012:3117 2a01:6340:2:501::20 2a02:c206:2241:2588::1 2a02:c600:4:62::1 2a02:898:218::1 2a03:e600:100::2 2a03:e600:100::4 2a03:e600:100::5 2a03:e600:100::6 2a03:e600:100::66 2a03:e600:100::68 2a03:e600:100::70 2a03:e600:100::71 2a03:4000:29:8a9:887f:9eff:feed:9e9 2a03:4000:62:8:c855:23ff:fef6:50ee 2a03:4000:66:15:18a0:6bff:fe90:3147 2a03:4000:7:dcc:14ac:f2ff:fea9:e4c7 2a06:d380:0:103::63 2001:1b60:3:221:3132:102:0:1 2001:1b60:3:239:1003:103:0:1 2001:41d0:304:200::3ea4 2001:620:20d0::24 2001:67c:289c::20 2001:67c:6ec:203:192:42:116:173 2001:67c:6ec:203:192:42:116:175 2001:67c:6ec:203:192:42:116:183 2001:67c:6ec:203:192:42:116:184 2001:67c:6ec:203:192:42:116:186 2001:67c:6ec:203:192:42:116:191 2001:67c:6ec:203:192:42:116:193 2001:67c:6ec:203:192:42:116:197 2001:67c:6ec:203:192:42:116:198 2001:67c:6ec:203:192:42:116:203 2001:67c:6ec:203:192:42:116:209 2001:67c:6ec:203:192:42:116:210 2001:67c:6ec:203:192:42:116:212 2001:67c:6ec:203:192:42:116:213 2001:67c:6ec:203:192:42:116:214 2001:67c:6ec:203:192:42:116:218 2001:67c:89c:702:1ce:1ce:babe:5 2001:67c:89c:702:1ce:1ce:babe:9 2001:910:1400:107::2 209.141.32.181 2605:6400:10:58f:8768:8283:1a62:bdc6 2605:6400:40:fde8:11c7:119b:aaf9:2722 2620:7:6001::160 31.133.0.210 45.66.35.22 45.66.35.35 45.94.31.68 50.118.225.228 51.210.104.67 51.210.107.182 51.210.111.180 5.255.100.26 54.36.209.253 62.171.137.169 77.48.28.239 80.82.78.14 8.209.106.19 86.106.74.250 88.80.26.3 93.95.231.14 94.16.121.91 95.211.174.137
Tiskni
Sdílej:
No pokud by k nim přibralili i Buřta, a všechno to šoupli do ťurmy někde na Sibiři, jdu do sklepa pro šáňo.
Kdysi jsem učinil zajímavou zkušenost. Kamarádovy WD disky, po zapojení do řadiče na mé desce žhavily jako svině. U něj byly ok. Na druhou stranu moje Seagate disky se chovaly takhle zase u něj. Takže zřejmě na chování firmware HDD mívá vliv i kooperace s řadičem.
Starší rotační disky mám už jen v úložišti doma. 3,5 palcové jsou značky Seagate a 2,5 palcové Toshiba. Dvě Toshiby umřely hned ze startu, ale zbytek drží. Mám dlouhodobě v plánu reorganizaci, tak už to moc neřeším.
Pokud jde o SSD používám všude k naprosté spokojenosti Samsung EVO (850 a 860). Ale někdo prý měl s nimi potíže.
Tak snad z toho zase nebyla ztráta dat jako u paní veterinářky.
A, u paní veterinářky nebyla ztráta dat způsobena schopností či neschopností admina, ale její vlastní iniciativou.
B, disky žhavili jako svině – [Oni] žhavili. V originále je ale disky žhavily jako svině. Tedy [Ony/Ty] disky žhavily, takže měly asi problém. Ne že by je někdo pekl někde na roštum nebo jim přilepšoval autogenem.
Nepatřím k těm, co by moc často marodili. A takhle mě neskrouhlo ještě nikdy nic. Opravdu to není moc příjemné, když se ve tři ráno z ničeho nic vzbudíš tím, že se dusíš a nevíš čím to je. Obzvláště když víš co se může přihodit.
Ja mam experimentalne pul roku na jednom stroji btrfs pres 3 rotacni disky s 3-nasobnyma kopiema a zatim dobry, uvidime az jeden z nich umre, jestli to btrfs ustoji stejne jako by to ustal mdraid 5.
Lépe než mdraid 5 ti to ustojí i Btrfs v raid 1 módu.
U Btrfs bys měl mít multidevice minimálně počet kopií + 1 disk, právě pro případ, že jeden umře. Protože takhle, když ti jeden z těch tří disků umře se ti Btrfs přepne do readonly a nedovolí rw remount, dokud nebude mít k dispozici zas 3 disky.
Pro tři disky bohatě stačí Btrfs v raid1 s jednou kopií, protože když jeden ten disk chcípne, obnoví chybějící bloky na ty dva co zbydou. A když ten chcíplý disk vyměníš, uděláš rebalance a jedeš bez ztráty kytičky furt pryč.
U Btrfs teoreticky platí, že čím více disků máš, tím lépe. Jenže prakticky to přináší nežádoucí komplikace, pokud jich máš víc, než kolik zvládne jeden řadič.
Vím o čem mluvím, protože takové pole mám. 3 řadiče a 12 disků. Pozůstatek z dob, kdy maximální kapacita jednoho HDD byla 2TB. Mám v plánu upgrade a budou to max. 4 velké HDD v řadiči na desce. Otázkou je, zda-li v takovém případě není lepší použít ZFS a menší NVME disky jako keš. I když asi ne, protože na ty soubory stejně lezu náhodně a mockrát se k nim nevracím.
MD raid, LVM a nad tím souborový systém Je zastaralé řešeníA co používáš v případě, kdy je ten disk navíc potřeba i šifrovat?
A nějaký rozumný důvod proč bych ho měl šifrovat bys po ruce neměl?
Je-li takový stroj napadený, je to šifrování na úrovni blokového zařízení k prdu, protože probíhá na nižší vrstvě. Smysl by to mělo možná tak u nějakého notebooku s citlivými daty, ale na domácím úložišti?
A nějaký rozumný důvod proč bych ho měl šifrovat bys po ruce neměl?1) krádež – ta hrozí prakticky všude 2) reklamace disku
Ad 1, A co bys chtěl ukrást? Dej vědět a klidně ti to nasdílím. Sdílení dat je totiž důležitou prevencí před jejich definiticní ztrátou. Já tedy v posmrtný život, či pobyt na nebesích nevěřím, ale kdyby snad náhodou, tak by mě po celou věčnost sralo ať už v pekle nebo na nebi, kdyby mnou pracně shromážděná data přišla vniveč.
Ad 2, Nereklamuji. A když, tak dříve nežli na tom disku nějaká smysluplná data jsou. A pokud mi nějaký disk doslouží, tak většinou projde i mechanickou destrukcí, pokud není recyklovatelný.
Ale abys neřekl.
Šifruji rovnou to blokové zařízení a používám dekapitované hlavičky.
Ehm, nechci to do toho kecat, ale nemáš pravdu.
U Btrfs se šifrují se pouze ukládané bloky dat a to pouze jednou, protože se pak už jenom čtou. Vícekrát se šifrují leda když používáš více šifrovaných blokových zařízení. Ovšem to už je jiná pohádka – pro paranoidní blázny. Já osobně vyhodnotil, že v praxi šifrování žádný smysl nemá, protože slabým článkem je stejně ten, kdo s těmi daty pracuje.
To máš sice pravdu, ale to zpomalení je marginální.
Opravdu si nedokážu představit, že by se někdo chtěl co dostat ke tvým datům zrovna tím, že by ti kradl počítač. To na něm syslíš klíč k tajemství vesmíru? Podle mne jsou prakticky veškerá data bez kontextu bezcenná. A pokud ti někdo štípne notebook, tak ho střelí za pár šupů o dál někomu, kdo veškerá tvá data přemázne ani nemrkneš.
Pak mám různé rozpracované věci, které jednou veřejné být mají, ale zatím nejsou hotové, takže ani veřejné.
To já taky a právě proto silně pochybuji, že by se našel blázen, který by tu práci chtěl udělat za mne.
A rodinné fotky? Tak to mohu jen politovat tvou bezmeznou naivitu. Všude se totiž válí tuny rodinných fotek. Většina je stejně na jedno brdo a pokud nemají popis, kdo je kdo a kde a kdy to je, je to jen nezajímavá datová makulatura. Ty obličeje zůstanou bezejmenné, stejně jako na fotkách starých alb, když zemřeli ti, co by k těm tvářím mohli přidat jména.
No jo. Já zapomněl Žako, že ty seš úplný Fanda Mrázek.
Ale jeden důvod, proč ty data šifrovat bych přeci jen pro tebe našel. A to je virtální disk v rámci AWS, atp.
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.
21.3. 13:52