Zobrazit příspěvky

Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.


Příspěvky - Logik

Stran: [1] 2 3 ... 65
1
Software / Btrfs - device missing
« kdy: 30. 11. 2021, 12:55:30 »
Ahoj,začal mi v jednom stroji blbnout disk s BTRFS - tak, že se občas odpojil (zmizel). Dal jsem tam další disk, přidal do btrfs raid1, spustil balance.Do druhýho dne starej disk opět zmizel, nicméně balance zatím proběhlo, takže systém v pohodě jede z novýho disku. Pocud dobrý. Jenže co dál. Jak se "zbavit" starýho disku?

Kód: [Vybrat]
btrfs device delete /dev/sda1 /Nefuguje, stěžuje si, že device /dev/sda1 nefunguje

Kód: [Vybrat]
btrfs device delete missing /Nefunguje, stěžuje si, že nejde odebrat disk, když je tam raid1. A to i po mount -o remount,degraded
Kód: [Vybrat]
btrfs balance start -f -mconvert=single -dconvert=single -sconvert=single /Bez problémů projde, ovšem poté

Kód: [Vybrat]
btrfs device delete missing /ERROR: error removing device 'missing': no missing devices found to remove

Reboot stroje vzdáleně nejde, protože grub-install se furt snaží instalovat grub na ten "zmizlej disk",takže nejde opravit bootloader. A riskovat, že po restartu ten starej disk nenajede a nenabootuje toa budu tam muset jet nechci.

Co s tím? Jak odstranit ten špatnej disk z btrfs?Tak jsem cestu našel, pomocí
Kód: [Vybrat]
echo "0 0 0" >/sys/class/scsi_host/host0/scanVynutil rescan SATA sběrnice, tím se zmizelej disk naštěstí příhlásil znovu, ale jako sdc.
Tak jsem udělal symlink /dev/sda1 /dev/sdc1 a následně už fungovalo btrfs device remove sda1.(Teda vlastně nevím, jestli byl symlink nutný a jestli nešlo rovnou zkusit odebrat sdc1.)

Nicméně otázka trvá: kdyby se disk odporoučel nadobro a nešel by vzkřísit, jak se ho bez restartu zbavit?

Kód: [Vybrat]
# btrfs fi show /Label: none  uuid: a73c52b4-ad9a-4831-9589-e275942b6436
    Total devices 2 FS bytes used 18.89GiB
    devid    2 size 512.00GiB used 22.03GiB path /dev/sdb1
    *** Some devices missing

# btrfs fi df /
Data, single: total=19.00GiB, used=18.21GiB
System, single: total=32.00MiB, used=16.00KiB
Metadata, single: total=3.00GiB, used=695.86MiB
GlobalReserve, single: total=52.27MiB, used=0.00B

#btrfs fi usage /
Overall:
    Device size:         640.00GiB
    Device allocated:          22.03GiB
    Device unallocated:         617.96GiB
    Device missing:         128.00GiB
    Used:              18.89GiB
    Free (estimated):         618.75GiB    (min: 618.75GiB)
    Data ratio:                  1.00
    Metadata ratio:              1.00
    Global reserve:          52.27MiB    (used: 0.00B)

Data,single: Size:19.00GiB, Used:18.21GiB
   /dev/sdb1      19.00GiB

Metadata,single: Size:3.00GiB, Used:695.86MiB
   /dev/sdb1       3.00GiB

System,single: Size:32.00MiB, Used:16.00KiB
   /dev/sdb1      32.00MiB

Unallocated:
   /dev/sda1     128.00GiB
   /dev/sdb1     489.97GiB









2
uetoyo: pokud chceš podobnej systém s virtuálníma prostředíma pro linux, tak na to je dobře použitelná Anaconda.

3
Hardware / Re:Ochrana proti zkratu 12V/2A
« kdy: 17. 10. 2021, 00:12:36 »
Kde jsem nechal vodiče? Už jen to, že saháš k takovéto otázce, tak tím potvrzuješ, že na jističi při vypínání napětí je. Protože pokud řešíš odpor vodičů, tak už jen řešíme v jakém poměru se napětí zdroje rozdělí mezi jistič a mezi dráty....Nebo snad chceš tvrdit, že vodiče mají takový odpor, že je těch 1.4 Ohmu jističe zanedbatelných? To snad ne...
Např. odpor 10m Cu 2,5mm^2 vodiče je cca 0.07 Ohmu. V jakém poměru se rozdělí napětí mězi jistič a drát tu snad nemusím počítat. A samozřejmě ano, můžeš klasickým jističem jistit i 100m vedení, to už se blížíš k hraně norem: právě proto, že už odpor drátů  začne ovlivňovat činnost jističe a jeho vypínací doby - a i v takovém případě máš na jističi pořád 2/3 napětí zdroje. A to jsi ještě vzal jistič, kterej má ten odpor poměrně malej.

4
Hardware / Re:Ochrana proti zkratu 12V/2A
« kdy: 16. 10. 2021, 22:12:32 »
RDa:To, co Ti nedochází, je, že z jističe se stává v okamžiku, kdy vybaví, zátěž.
(Proč tomu tak je tu vysvětlovat teoreticky radioing) A tu zátěž musí zdroj utáhnout, jinak prostě jistič nevybaví. V případě zkratu máš během vybavování mezi póly jističe napětí zdroje, neboť to je jediný odpor v obvodu  (přesněji o řády větší odpor než všechny ostatní v obvodu). Proto jistič nepotřebuje nulu: v okamžiku vybavení je nulou druhý pól jističe. Tedy jistič MÁ K DISPOZICI NAPĚTÍ ZDROJE.

Toto napětí zdroje definuje proud protékající přes jistič v okamžiku vybavování. A pokud není toto napětí dost velké, tak jistič nemá sílu překonat pružinu. Na to, popsat, co se v takovém případě děje, už si netroufám - pravděpodobně tam bude oscilovat pružina, tím i oscilovat protékající proud (jak se bude měnit energie odebíraná z magnetického pole a tím i impendance cívky), ten protékající proud ale může být v krátkých časových intervalech podstatně větší, než jaký je jmenovitý proud jističe.

Ale z toho, že jistič je v okamžiku vybavování zátěží, je zcela patrné, že napětí v obvodu má na funkci jističe vliv.

5
Sítě / Re:Wifi cez 4 pokoje
« kdy: 09. 10. 2021, 10:55:40 »
Velmi doporučuju se vyhnout krimpování konektorů (btw. to bez vybavení člověk neudělá) a ukončit tahanej kabel zásuvkama (prodávaj se i "na omítku", když je nebudeš chtít zasekávat do zdi).
Jednak ty narozdíl od konektorů dobře zapojí i člověk, co to nedělal, jednak když to zapojíš blbě (ať už přehodíš dráty, nebo se Ti správně neprořeže drát), jde to narozdíl konektorů opravit (pravda, dělaj se rozpojovací konektory, ale jsou co vím drahý), jednak to má podstatně větší "šťábní kulturu", jednak až se Ti po dvou letech ulomí konektoru zobáček, vyměníš jen krátkej patchkabel (mezi zásuvkou a PC), zatímco na zásuvce se moc nemá co pokazit.
===
Co se týče směrový antény, tak ani ta dle zákona nemůže překročit vyzářený výkon,https://shopdelta.eu/e-i-r-p-effective-isotropic-radiated-power-an-equivalent-effective-isotropic-radiated-power_l2_aid837.html
 správně bys měl při jejím zapojení limitovat výkon Wifi karty. To, proč je směrová anténa lepší, než všesměrovbá, není kvůli vysílacímu výkonu, ale kvůli lepšímu příjmu. (Z čehož mj. plyne, že pokud nechceš porušovat max. povolenej vyzářenej výkon, tak potřebuješ směrové antény na obou koncích bezdrátového spoje).
===
Zapik:To je sice správná teorie, ale přecijenom teorie. Takhle bych mohl pokračovat dál a tvrdit, že wifi je vůbec nespolehlivé a jediná správná filosofie je mít vše drátem. Což je sice pravda, ale má to stejnej problém, jako Tvoje stanovisko: také zdůrazňuje jen výhody, a zapomíná na nevýhody: drát není vždy šikovnej, a s každým dalším AP ti roste počet zařízení, tedy i vynaložené peníze (i za provoz), roste počet věcí, co se mohou pokazit, a také se zesložiťuje zapojení.

IMHO  správná filosofie je, použít nejjednodušší FUNKČNÍ řešení. Vzhledem k tomu, že wifi jednu běžnou zeď prostřelí zpravidla úplně v pohodě, tak řešení se 4 AP je zde overkill, na 99% bude dobře fungovat AP v pokoji 1 a 3.

6
Hardware / Re:Je tento USB-C kabel v něčem lepší(jiný)?
« kdy: 06. 10. 2021, 14:57:31 »
USB C je obousměrný konektor, kde do verze 3.2 gen 2 šel po dvou drátech (ve skutečnosti dvou párech drátů) stejnej signál. Od (zpětně kompatibilní) verze 3.2 2x2 může jít po každym tom páru signál jinej, což zdvojnásobí propustnost. Ale vyžaduje to, aby ten kabel nebyl "ošizenej" a měl opravdu zapojený oba páry drátů, což některý "jen" 3.2 gen 2 neměly (a pak ovšem se zařízeníma, kde byl stejnym způsobem ošizenej konektor, nefungovaly, nebo fungovaly jen při jednom zapojení).

Teda 3.2 gen 2 defakto značí výrobcem garantovanou dosažitelnou rychlost (dosažitelné frekvence na kabelu), a to 2x2 značí, že výrobce garantuje správné zapojení a fungování v režimu "dualchannel".

Viz https://diit.cz/clanek/usb-32-prinasi-nazvoslovny-gulas a především diskuse pod článkem.
PS: Teda je ještě tady ta věc, že když po každym páru běží jinej signál, tak možná musí bejt kabel o něco kvalitnější, aby nebyly přeslechy. Takže ani správně zapojenej "jen gen 2" kabel nemusí v režimu 2x2 fungovat správně.


7
Hardware / Re:Kombinovanie RAM v PC
« kdy: 06. 10. 2021, 11:39:53 »
Nedramatizujte to. Samozřejmě koupit stejné časování a čipy je lepší - ale v 99% jede PC bez problémů, i když se tam narve "úplně něco  jinýho".
Takže pokud nejde za rozumnou (tzn. v řádech malých desítek minut) najít stejné paměti či paměti se stejnejma čipama, tak kup cokoli "kompatibilního" (tj. 2x8GB předpokládám DDR4). Stejně je vždy velmi záhodno projet zakoupené paměti memtestem, takže na případnej problém přijdeš a můžeš je vrátit/vyměnit, kdybys byl v tom 1% (či spíš 0,1%), kdy to zlobí. Utrácet peníze za 2x16GB (pokud bys teda nechtěl 42GB RAM) je zbytečné. Doby, kdy RAM byla alchymie a muselo se kolem nich chodit po špičkách už je naštěstí dávno pryč.

PS: Zachovávat výrobce modulů (při jiných čipech) moc smyslu nemá - výrobců čipů je pár a všichni výrobci modulů to dělaj +- stejně. Jako když to bude stát stejně, tak je to "malý plus". Ale nepřiplácel bych za to. Jestli něco, tak podstatnější je výrobce čipů, co jsou na tom modulu, ale zas si nemyslím, že má smysl vrážet do zjišťování skutečně použitejch čipů  víc než minimální množství času - stejně Ti výrobce začne najednou montovat jiný, (obzvlášť u pamětí, co se prodávaj za rozumnou cenu), takže nemáš jistotu, co koupíš.

8
Ink: Já myslím, že píšeme to samé. Nebo tím narážíš na "lhal v životopise"? I kdyby to lhaní v životopise bylo nereálné, tak by to byla věc, na které by se mohl zaměstnanec točit a věc by to podstatně měnilo, proto jsem to radši zmínil.

PanVP: Máš pravdu, ale to bude muset prokázat u soudu.
Ne, nebude. Zaměstnavatel bude muset u soudu prokázat opak. To je právě podstatné: zaměstnavatel musí ukázat, že škoda nevznikla jeho zaviněním, ale zaviněním zaměstnance.Jako samozřejmě u soudu prvního stupně se dá nadít čehokoli, ale obecně todle je tak jasný případ, že bych se nebál - samozřejmě nepodcenit právní pomoc atd....

Ale, jak už píšou jiní, na 99% tu žádný soud nebude, pokud není šéf ještě větší magor, než se zdá. Ale je podstatné, aby tazatel dal asertivně - nikoli konfliktně ! - najevo, že zná svá práva a že ze sebe nenechá udělat obětního beránka, který se bude šéfovi skládat na plat (těmadle slovama bych to asi nepodával, byť je možný, že na některý typy šéfů by to vlastně fungovalo :-)).

Jinak souhlasím, že z firmy je třeba odejít, a pokud bude šéf souhlasit, tak bych zbytek výpovědní doby pracoval na odstranění průšvihů. Ale ono bez pomoci nějakého seniora to možná nebude mít moc smysl, a pokud je projekt opravdu spatlanej, tak může bejt rozumnější ho zahodit.
Ale nemá smysl nějak víc nad rámec pracovních povinností řešit problémy, které jdou ve skutečnosti za vedením firmy, a tím ze sebe zároveň dělat vola a obětního beránka (takže asi vykastrovanýho obětního beránka? ty zvířátkovský metafory jsou zajímavý.... :-)). Projevit dobrou vůli a nějak se v rozumné míře podílet na nápravě, pokud bude vůle i z druhé strany, to ale jo.

PS: Co je také podstatné, zaměstnavatel nesmí jednostranně strhávat náhradu škody ze mzdy (např.https://www.mesec.cz/clanky/muze-vam-zamestnavatel-strhnout-ze-mzdy-nahradu-skody-kterou-jste-mu-zpusobili/). Tedy pokud chce strhávat plat, musí s tím zaměstnanec souhlasit, jinak musí podávat žalobu zaměstnavatel. Jakékoli jednostranné srážky ze strany zaměstnavatele jsou nelegální, i kdyby škoda reálná byla.

9
Důležitý si je uvědomit:Pokud jsi nelhal v životopise, tak je situace zcela v zodpovědnosti firmy, která Ti přidělila úkol nad Tvoje schopnosti. A to i nad Tvoje schopnosti rozpoznat, že jde o úkol nad Tvoje schopnosti (to je právě součást těch zkušeností, které si neměl).

Dále pak, odpovědnost za škodu vyžaduje, cituji:
"zaviněným porušením povinností při plnění pracovních úkolů nebo v přímé souvislosti s ním."
a
"Zaměstnavatel je povinen prokázat zavinění zaměstnance"

Ty jsi škodu zaměstnavateli ve skutečnosti nezpůsobil. Ty jsi odvedl práci která sice nebyla dobrá, ale byla naprosto adekvátní Tvému životopisu a Tvým zkušenostem. To, že zaměstnavatel Tvůj kód nezkontroloval, neotestoval, neprovedl code-review nějakým seniorem, ani nealokoval na daný projekt patřičné zdroje, není Tvoje chyba - a to je skutečná příčina zaměstnavatelovy škody.

10
Vývoj / Re:Agregace velkeho mnzstvi stream dat
« kdy: 22. 09. 2021, 19:27:10 »
Pokud bys šel tímdle směrem, tak to holt je úloha spíš na C/C++, byť i v Javě se asi dá psát úsporně (např. si předalokovat bytový vektor a z něho pak "alokovat" stringy sám, ale pak je trochu otázka, proč to psát v JAVĚ.... - ale jinak ohledně toho mě neber moc vážně, Javu znam z rychlíku).
Na C++ existuje Kafka klient:https://docs.confluent.io/clients-librdkafka/current/overview.html
A ohledně 7GB paměti - to je hodně? 8GB modul stojí litr, pokud ten stroj, kde to má běžet, by to fakt nezvlád.... Oproti ceně, za "kterou to napíšeš", to jsou drobný.

11
Vývoj / Re:Agregace velkeho mnzstvi stream dat
« kdy: 22. 09. 2021, 18:22:34 »
Citace
Dik za hint, tohle mi asi ale nepomuze. Prevod na integer otisk postaci pro agregaci, ja to ale pak zase potrebuju expandovat na puvodni stringy a poslat dale do sveta.
A co Ti brání si držet tabulku: "id metriky":"metrika"? S 90 milionama metrik to dělá řádově 4GB.....
To, co je tady problém je opačná otázka, jak dostatečně rychle zjistit ID z metriky, tak aby bylo rozumně spojitý (neděravý) a tedy to zabralo rozumně paměti. A tady mi to zní jako perfektní úloha na nějakou formu "perfektního hashování".

Anebo, ono umístění řetězce v paměti je ideální "perfektní hash", navíc zadarmo a reversibilní :-). Takže se opravdu úloha redukuje na perfektní zahašování stringu. Stačí si uvědomit, že klíč k redukci paměťové náročnosti je v tom, držet řetězec s názvem metriky v paměti pouze jednou a vždy na něj pouze odkazovat.
Pravda, v takto jednoduchém modelu má hashovací klíč 8 bytů, ale to furt není nic, co by se do rozumnýho stroje do paměti nevešlo. A popř. jde pak ještě perfektně hashovat ten 64bit pointer do nějakého 32bit čísla, kdybys na tom chtěl pálit programátorskej čas (jakože kdyžtak dokoupit paměť by vyšlo levnějc :-)).

EDIT: A nebo zůstat u indexace 4bit integerem, a název metriky držet v datové struktuře spolu s agregovanými hodnotami, to je vlastně ještě přirozenější, než mít "extra slovník".

12
Vývoj / Re:Agregace velkeho mnzstvi stream dat
« kdy: 22. 09. 2021, 17:39:37 »
Převeď si to do nějakýho rozumnýho binárního formátu. 90 milionů metrik popíšeš místo stringem o velikosti desítek bajtů jedním integerem, čímž se Ti velikost zprávy smrskne skoro desetkrát a vejde se Ti to do paměti.....

13
Hardware / Re:SSD nebo Wifi v M.2 slotu
« kdy: 21. 09. 2021, 17:26:09 »
Ach jo.Zkus si znova přečíst, co jsi napsal:
Citace
ale otázka zní zda neexistuje redukce PCIe E key na něco použitelného, biď by to byla jen mSATA
a zamyslet se, jestli není na místě omluva místo arogance. Tím se omlouvám ale na toto téma končím - chtěl jsem Ti pomoci zpětnou vazbou, ale jestli o ni nemáš zájem, tak to už je Tvá věc.





14
Hardware / Re:SSD nebo Wifi v M.2 slotu
« kdy: 21. 09. 2021, 13:12:00 »
LivingLegend:
není to E-key, ale A-key. A odkaz na redukci A-Key na PCIe již v diskusi zazněl.Tak s nediv, že když si nepřečteš co odpovídali lidé dřív, píšeš do diskuse blbiny a ještě strašnou češtinou, tak že sklidíš nelichotivou reakci.


15
Hardware / Re:SSD nebo Wifi v M.2 slotu
« kdy: 20. 09. 2021, 21:40:32 »
No, A - key má vyhrazený piny pro PCI-Ex2.
https://pinoutguide.com/HD/M.2_NGFF_connector_pinout.shtml

Ale je otázka, jestli "jsou zapojený" - není výjimkou, že výrobce použije "univerzální slot", ale zapojí jen to, co potřebuje. Změřit to asi normální člověk nedá, tak leda vysledovat, jestli k danejm pinům (viz pinout) směřujou dráhy.


Pokud jsou zapojený, tak by mělo todle:
https://www.aliexpress.com/item/1005003022966607.htmlpomoci.

Otázka je, jestli se dá "totéž" sehnat za nějakou rozumnou cenu (výrobní cena by měla bejt tak dolar, ale asi to moc ) - to už nechám na dohledání tazateli.. No a samozřejmě pak to chce PCIE SSD, ne SATA - tedy M-key.

Stran: [1] 2 3 ... 65