V MikroTik RouterOS bylo nalezeno šest zranitelností společně pojmenovaných MikroTrick umožňujících útočníkovi, pokud má přístup k SSH, získat plnou kontrolu nad zařízením bez nutnosti autentizace. Ve verzích RouterOS 7.25beta3, 7.24.2, 7.23.4 a 6.49.21 je již opraveno.
Byla vydána verze 9.5 open source unixového operačního systému NetBSD (Wikipedie). Přehled novinek v poznámkách k vydání. Jedná se poslední vydání řady NetBSD 9. Doporučen je přechod na NetBSD 11 nebo NetBSD 10.
Akční adventura State of Mind je na portále GOG.com zdarma, akce trvá do 10. září.
Na Kickstarteru běží kampaň na podporu malého robotický psa Petoi Quaddle. Postaven je na ESP32-S3. V několika variantách. S řadou senzorů. Programovat lze pomocí Pythonu, C++ nebo i vizuálních bloků. Zkoušet a trénovat lze v simulátoru.
Dětem začala škola a nedobrovolně se tak musí vzdělávat. Avšak pro dospělé, kteří se chtějí vzdělávat nebo naopak se o vědomosti podělit, je tu Virtuální Bastlírna - jako každý měsíc si můžete online a zdarma nezávazně popovídat o vědě a technice nejen s bastlíři, ale i s vývojáři, vědci nebo profesory. A čemu se strahováci budou věnovat? Blíží se KiCAD 11 s nespočtem novinek, z nichž zde musí zmínit alespoň možnost kótování a závislostí z
… více »Asahi Linux, tj. Linux pro Apple Silicon, oficiálně podporuje čipy M3 (M3, M3 Pro a M3 Max).
Společnost Acer oslavila 50 let. Na tiskové konferenci next@acer představila řadu novinek. Vypíchnout lze přenosný ePaper displej Acer EP130K, přenosné řešení se třemi displeji Acer PD163Q P3 nebo herní handheld a notebook v jednom DualPlay Mini.
Server SiFive BigSky SF-2U870 2U je založený na jádře SiFive P870-D, zatím je naintegrovaných 32 jader 256 GB RAM 2 GHz, škálovat lze do 256 jader na čip. O něco podrobnější popis serveru v článku SiFive BigSky Ships the First RISC-V Server. Is the GPU Head Node the Prize? na futurumgroup.com. Asi ani tento čip nebude na úrovni nejlepších 64-bit ARMů a AMD Zenů, ale splňuje RVA23 specifikaci a je podporovaný Ubuntu 26.04 LTS a RHEL 10. V článku je
… více »Na YouTube lze zhlédnout nový celovečerní dokumentární film The Story of VS Code | Official Documentary věnovaný Visual Studio Code.
Farid Abdelnour se v příspěvku na blogu rozepsal o novinkám v nejnovější verzi 26.08.0 editoru videa Kdenlive (Wikipedie). Ke stažení také na Flathubu.
2.11.2018 15:15
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
2.11.2018 15:57
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
mkfs.btrfs -d raid1 -m raid1 /dev/disk1 /dev/disk2), tak je další konverze zbytečná. Pokud jste btrfs vytvořil na single disku, tak stačí konverzi (přes balance) provést pouze jednou. Dále můžete přidávat další disky a stále to bude FS typu raid1.
A vzhledem k tomu že spojené disky do jednoho brtfs mají jeden společný label tak jediné viditelné odlišovátko je právě sdX.Ano, to je správně. Právě proto se používá UUID (v nejhorším LABEL) a nikoliv konkrétní diskové zařízení.
root@sever:~# btrfs device usage /srv/dev-disk-by-label-btrfs1
/dev/sdg1, ID: 6
Device size: 1.82TiB
Device slack: 3.50KiB
Unallocated: 1.82TiB
/dev/sdj1, ID: 1
Device size: 10.91TiB
Device slack: 3.50KiB
Data,RAID1: 10.35TiB
Metadata,RAID1: 12.00GiB
System,RAID1: 32.00MiB
Unallocated: 563.97GiB
/dev/sdk1, ID: 2
Device size: 10.91TiB
Device slack: 3.50KiB
Data,RAID1: 10.35TiB
Metadata,RAID1: 14.00GiB
System,RAID1: 32.00MiB
Unallocated: 563.97GiB
/dev/sdl1, ID: 3
Device size: 5.46TiB
Device slack: 3.50KiB
Data,RAID1: 4.90TiB
Metadata,RAID1: 4.00GiB
Unallocated: 563.03GiB
/dev/sdm1, ID: 4
Device size: 3.64TiB
Device slack: 3.50KiB
Data,RAID1: 3.09TiB
Metadata,RAID1: 2.00GiB
Unallocated: 564.02GiB
/dev/sdp1, ID: 5
Device size: 1.82TiB
Device slack: 3.50KiB
Unallocated: 1.82TiB
První dva disky (sdj, sdk) jsem vytvořil rovnou raid1.
Později přidal sdl a provedl balanc. Ten trvla 5 hodin.
A naposledy přidal společně sdg a sdp.
Jde o to že to nepíše že tam je raid1. Myslel jsem tedy že musím provést rebalanc.
2.11.2018 19:03
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
btrfs fi df /srv/dev-disk-by-label-btrfs1Rebalance celého fs fakt není potřeba.
Sestavil jsem btrfs raid1 ze dvou nových disků. Nakopíroval data a tím vyprázdnil další disk. Přidal jsem ho do btrfs jako raid1 a spustil balanci. Ta trvala 5 hodin, což ještě šlo. Pak jsem připojil další a balanc už trvá dva dny!!!!!! a je zřejmé dle btrfs balance status na 54% procentech. Vzhledem k tomu že jsem měl v plánu takto připojit ještě 3 disky tak to budu dělat měsíc se vzrůstající kapacitou.
Uf. Tady si nejsem jistý, čeho chceš dosáhnout, respektive co se myslí tím dalším diskem.
Obecně Btrfs podporuje RAID1 jen na 2 discích. Tedy v tom smyslu, že když tam přidáš další disky, RAID1 "pouze" garantuje, že data i metadata budou zapsaná celkově aspoň dvakrát na dvou různých discích. Ale není specifikováno na kterých. Není tam, pokud se nepletu, žádná garance ohledně toho, jak to bude se třemi nebo čtyřmi disky.
Předně — a někdo mě, doufám, opraví, jestli se pletu —, přidání třetího a dalších disků do RAID1 nezvyšuje redundanci toho RAIDu; vždy to pole bude spolehlivě odolné jenom proti selhání jednoho disku; selhání několika disků může zničit filesystém nebo znepřístupnit některé soubory / bloky. Tedy jde o jakýsi poor man's RAID s využitím místa jako RAID1 a redundancí jako RAID5, což není zrovna dobré.
Pro konfiguraci odolnou vůči výpadku dvou disků (jestli je tohle cílem) je lepší zvolit Btrfs RAID6, kolem kterého donedávna poletovaly jakési fámy kolem spolehlivosti, než je konečně rozptýlily nedávné opravy. (Navíc se dnes už dá ze všech Btrfs RAIDů bootovat přímo GRUBem, pokud mu UEFI ukáže dostatek disků pro přečtení filesystému.)
Pokud jde o sudý počet disků, vhodná konfigurace by mohla být něco ve stylu "RAID10" (pokud je v pořádku mít jen 50% celkového diskového prostoru). Pro jakýkoliv počet disků pak bude fungovat RAID5 a RAID6.
Pokud to má odolat selhání víc než dvou disků, Btrfs na to není vhodný kandidát. Pak je potřeba ZFS, které takové typy redundance umí. Btrfs zatím nemá nic takového jako RAIDZ3. Totéž platí pro RAID1 replikaci přes víc než dva disky — taky jednoznačně případ pro ZFS.
A druhá podotázka která s btrfs nesouvisí spíš na obecné úrovni. A vychází z toho co jsem už pogoogloval. Mohu ve fstab nastavit aby na konkrétních portech sata byly sda, sdb, sdc, ... disky tak jak chci a neměnilo se to? Potřebuji to čistě kvůli organizaci. A pokud to jde, jak to udělám :) Nevím ani jak se spustí nejakej textovej editor/notepad :)
Ve fstab tohle není, ale jde to. (Účel fstab je celkem ortogonální k tomu, jak pojmenovat disky.)
Nejlepší je nepoužívat /dev/sda a podobné uzly a místo toho dát do fstab UUID, která se dají zjistit například pomocí blkid nebo lsblk -f. To je popsané zde, se všemi možnostmi a podrobnostmi.
Pokud i přes všechna doporučení ve výše odkazovaném článku trváš na stabilním pojmenování disků (aby /dev/sdb byl vždy tentýž disk atp.), dá se to zařídit pomoci Udev pravidel.
Nevím ani jak se spustí nejakej textovej editor/notepad :)
S ohledem na to, co o sobě tvrdíš, bych jako vhodnou volbu doporučil Midnight Commander (mc). Ten má editor buď přes F4 při procházení adresářů nebo pomocí příkazu mcedit.
V grafickém prostředí je editorů spousta, třeba KWrite, Kate a jejich ekvivalenty ve spoustě dalších prostředí. Ale jde o to, že pro editaci něčeho pod rootem se většinou nedoporučuje spouštět grafické programy, tak nějak z principu, na základě velikosti trusted code base a podobných pouček.
cat /sys/block/sdX/device/model - vypíše typ disku a příkazem cat /sys/block/sdX/device/wwid - vypíše přesnou identifikaci disku. V mém případě:
$ cat /sys/block/sda/device/model WDC WD10J31X-00U $ cat /sys/block/sda/device/wwid t10.ATA WDC WD10J31X-00U3VT0 WD-WX91E150AKSM $
user@stroj:~$ lsblk -o 'KNAME,LABEL,FSTYPE,MODEL,HCTL,UUID' KNAME LABEL FSTYPE MODEL HCTL UUID sda Samsung SSD 850 0:0:0:0 sda1 raid btrfs 8d567f20-2ab3-436e-a52f-c7ed7e1c8879 sdb Samsung SSD 850 0:1:0:0 sdb1 raid btrfs 8d567f20-2ab3-436e-a52f-c7ed7e1c8879 sdc Samsung SSD 840 1:0:0:0 sdc1 ntfs 5A48179E481777C9 sdc2 linux btrfs 4f113a2b-1467-4c09-bd4f-6a3355a0664dViz help.
root@sever:~# btrfs device usage /srv/dev-disk-by-label-btrfs1
/dev/sdc1, ID: 1
Device size: 10.91TiB
Device slack: 3.50KiB
Data,RAID1: 10.07TiB
Metadata,RAID1: 11.00GiB
System,RAID1: 32.00MiB
Unallocated: 850.97GiB
/dev/sdi1, ID: 6
Device size: 1.82TiB
Device slack: 3.50KiB
Data,RAID1: 1011.00GiB
Metadata,RAID1: 1.00GiB
Unallocated: 851.02GiB
/dev/sdk1, ID: 2
Device size: 10.91TiB
Device slack: 3.50KiB
Data,RAID1: 10.07TiB
Metadata,RAID1: 10.00GiB
System,RAID1: 32.00MiB
Unallocated: 850.97GiB
/dev/sdl1, ID: 3
Device size: 5.46TiB
Device slack: 3.50KiB
Data,RAID1: 4.62TiB
Metadata,RAID1: 6.00GiB
Unallocated: 850.03GiB
/dev/sdm1, ID: 4
Device size: 3.64TiB
Device slack: 3.50KiB
Data,RAID1: 2.80TiB
Metadata,RAID1: 5.00GiB
Unallocated: 850.02GiB
/dev/sdp1, ID: 5
Device size: 1.82TiB
Device slack: 3.50KiB
Data,RAID1: 1012.00GiB
Metadata,RAID1: 1.00GiB
Unallocated: 850.02GiB
2.11.2018 19:10
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
Přiznám se, že teď si mě zaskočil. No ale budiž.Mě taky.
Je blbost udělat btrfs raid1 na dvou discích a pak přidávat další. Nejlepší je, udělat ho rovnou na všech najednou. To za prvé.Ano, to je jistě nejlepší, ale pokud data převádí z jiných disků, tak to nejspíš jinak udělat nemůže. A nevidím nic špatného na tom udělat btrfs z několika disků a postupně tam další přidávat. To je jedna z výhod multidevice fs. Sám mám několik fs, které už se dokonce několikrát přestěhovaly na nové disky. Nový přidat, starý odebrat. Od toho to je.
Za čtvrté. Právě proto by se měl čas od času pouštět na btrfs scrub, který zajistí, že se tahle kontrola udělá preventivně a vy tím pádem zjistíte, že nějaký disk umírá – dřív než skutečně chcípne.A k tomu bych dodal současně dělat i smart testy disků, každý den short test a třeba jednou týdne long test. A pokud něco detekuje smart, tak disk vyjmout a vyměnit (tj nečekat, až disk vykopne sám btrfs).
KERNEL=="sd*", DEVPATH=="/devices/pci0000:00/0000:00:0c.0/0000:07:00.0/host19/port-19:0/end_device-19:0/target19:0:0/19:0:0:0/*", SYMLINK+="sdz%n"
Je toto správně? Včetně té hvězdy na konci devpath? Děkuji
4.11.2018 01:10
Josef Kufner | skóre: 70
4.11.2018 16:34
/dev/disk/by-*
4.11.2018 02:30
Josef Kufner | skóre: 70
ls -l). Na názvu ani umístění toho souboru nijak nezáleží.
Aby to bylo jednodušší, udev vyrobí také symlinky v /dev/disk/by-* podle různých detekovaných vlastností toho disku a oddílů na něm. Případně ještě lze na mnoha místech použít zápis LABEL=něco, UUID=něco, PARTLABEL=něco a PARTUUID=něco.
Nazvy oddílů jsou uloženy v GPT tabulce na disku (MBR to neumí). Druhý název je v hlavičce souborového systému. Obojí jde snadno změnit (gparted, e2label, fatlabel, …). OMV bude zobrazovat buď tento název, nebo to, co jsi napsal do /etc/fstab, nebo název toho speciálního souboru.
3.11.2018 18:11
Josef Kufner | skóre: 70
lsblk -o NAME,PARTLABEL,LABEL,UUID,MOUNTPOINT
3.11.2018 21:13
btrfs check --repair /dev/sdc1
ale píše
enabling repair mode
/dev/sdc1 is currently mounted. Aborting.
a i přestože jsem provedl umount /srv/dev-disk-by-label-btrfs1
Po restartu je btrfs zase připojen a funkční.
Netušíte co by to mohlo být? Děkuji...
PS: zlatý wokna :)
sudo umount /dev/sdc1 # kontrola zda uz neni pripojen (kdyz nezobrazi nic, neni) mount | grep sdc1jinak po restartu logicky mas pripojene opet vse to co se pripojuje automaticky, to mas v souboru /etc/fstab
Tiskni
Sdílej:
