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.
Jarní konference EurOpen.cz 2025 proběhne 26. až 28. května v Brandýse nad Labem. Věnována je programovacím jazykům, vývoji softwaru a programovacím technikám.
Na čem aktuálně pracují vývojáři GNOME a KDE Plasma? Pravidelný přehled novinek v Týden v GNOME a Týden v KDE Plasma.
Před 25 lety zaplavil celý svět virus ILOVEYOU. Virus se šířil e-mailem, jenž nesl přílohu s názvem I Love You. Příjemci, zvědavému, kdo se do něj zamiloval, pak program spuštěný otevřením přílohy načetl z adresáře e-mailové adresy a na ně pak „milostný vzkaz“ poslal dál. Škody vznikaly jak zahlcením e-mailových serverů, tak i druhou činností viru, kterou bylo přemazání souborů uložených v napadeném počítači.
Byla vydána nová major verze 5.0.0 svobodného multiplatformního nástroje BleachBit (GitHub, Wikipedie) určeného především k efektivnímu čištění disku od nepotřebných souborů.
Na čem pracují vývojáři webového prohlížeče Ladybird (GitHub)? Byl publikován přehled vývoje za duben (YouTube).
Provozovatel čínské sociální sítě TikTok dostal v Evropské unii pokutu 530 milionů eur (13,2 miliardy Kč) za nedostatky při ochraně osobních údajů. Ve svém oznámení to dnes uvedla irská Komise pro ochranu údajů (DPC), která jedná jménem EU. Zároveň TikToku nařídila, že pokud správu dat neuvede do šesti měsíců do souladu s požadavky, musí přestat posílat data o unijních uživatelích do Číny. TikTok uvedl, že se proti rozhodnutí odvolá.
Společnost JetBrains uvolnila Mellum, tj. svůj velký jazykový model (LLM) pro vývojáře, jako open source. Mellum podporuje programovací jazyky Java, Kotlin, Python, Go, PHP, C, C++, C#, JavaScript, TypeScript, CSS, HTML, Rust a Ruby.
Vývojáři Kali Linuxu upozorňují na nový klíč pro podepisování balíčků. K původnímu klíči ztratili přístup.
V březnu loňského roku přestal být Redis svobodný. Společnost Redis Labs jej přelicencovala z licence BSD na nesvobodné licence Redis Source Available License (RSALv2) a Server Side Public License (SSPLv1). Hned o pár dní později vznikly svobodné forky Redisu s názvy Valkey a Redict. Dnes bylo oznámeno, že Redis je opět svobodný. S nejnovější verzí 8 je k dispozici také pod licencí AGPLv3.
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:
