Patnáctý ročník ne-konference jOpenSpace se koná 4. – 6. října 2024 v Hotelu Antoň v Telči. Pro účast je potřeba vyplnit registrační formulář. Ne-konference neznamená, že se organizátorům nechce připravovat program, ale naopak dává prostor všem pozvaným, aby si program sami složili z toho nejzajímavějšího, čím se v poslední době zabývají nebo co je oslovilo. Obsah, který vytváří všichni účastníci, se skládá z desetiminutových
… více »Program pro generování 3D lidských postav MakeHuman (Wikipedie, GitHub) byl vydán ve verzi 1.3.0. Hlavní novinkou je výběr tvaru těla (body shapes).
Intel vydal 41 upozornění na bezpečnostní chyby ve svých produktech. Současně vydal verzi 20240514 mikrokódů pro své procesory řešící INTEL-SA-01051, INTEL-SA-01052 a INTEL-SA-01036.
Společnost Raspberry Pi patřící nadaci Raspberry Pi chystá IPO a vstup na Londýnskou burzu.
Google na své vývojářské konferenci Google I/O 2024 představil řadu novinek. Keynote byl věnován umělé inteligenci (DeepMind, Gemini, Responsible AI).
V Gitu bylo nalezeno 5 zranitelností. Opraveny jsou ve verzích 2.45.1, 2.44.1, 2.43.4, 2.42.2, 2.41.1, 2.40.2 a 2.39.4. Útočník může připravit repozitář tak, že při jeho klonování (git clone) může dojít ke spuštění libovolného kódu.
Virtualizační softwary VMware Workstation Pro a VMware Fusion Pro jsou nově pro osobní použití zdarma. Softwary VMware Workstation Player a VMware Fusion Player končí.
Linuxová distribuce Endless OS (Wikipedie) byla vydána ve verzi 6.0.0. Přehled novinek i s náhledy v příspěvku na blogu, poznámkách k vydání a také na YouTube.
Byl vydán Mozilla Firefox 126.0. Přehled novinek v poznámkách k vydání, poznámkách k vydání pro firmy a na stránce věnované vývojářům. Vylepšena byla funkce "Zkopírovat odkaz bez sledovacích prvků". Přidána byla podpora zstd (Zstandard). Řešeny jsou rovněž bezpečnostní chyby. Nový Firefox 126 je již k dispozici také na Flathubu a Snapcraftu.
Grafana (Wikipedie), tj. open source nástroj pro vizualizaci různých metrik a s ní související dotazování, upozorňování a lepší porozumění, byla vydána ve verzi 11.0. Přehled novinek v aktualizované dokumentaci.
mkfs.ext4
pomocí nastavení stride
a stripe-with
na hodnoty velikosti chunku a jeho trojnásobek (pro 3 datové disky), sdělí filesystému, jak je organizované podstavné RAID pole. Ale šifrování tam vloží hlavičku a začátek blokového zařízení pro ext4 může být jinde než je zarování raid pole a potřeboval bych tedy zjistit, kde vlastně začíná datová oblast a jak nastavit LUKS nebo ext4, aby finální filesystem byl v souladu s raidem. Kolegové s RH se tím někdy zabývali? Tohle na serverech by se mohlo nekdy stávat. Snad.
Řešení dotazu:
V rámci stavby domácího serveru mám RAID 5 pole nad 4 disky a nad ním LUKS. Nad Luksem chci mít filesystem ext4 (nebo xfs).
RAID na úrovni filesystému by takový problém vyřešil automaticky, aby se tím uživatel nemusel explicitně zabývat. A navíc by taky fungoval jako RAID se vším, co RAID slibuje, na rozdíl od téhle iluze RAIDu, která po poškození dat na jednom disku proaktivně naschvál poškodí data na všech ostatních discích.
--align-payload=3M
by to mohlo zarovnat na správnou rovinu. Jde to nějak možné zkontrolovat. zkusil jsem si backup luks headeru, abych věděl jak je hlavička velká a dostal soubor o velkosti 257 bloků velikosti 4kB.
mdadm --detail /dev/md126 /dev/md126: Version : 1.2 Creation Time : Sat Jan 6 19:15:22 2018 Raid Level : raid5 Array Size : 7296182592 (6958.18 GiB 7471.29 GB) Used Dev Size : 2432060864 (2319.39 GiB 2490.43 GB) Raid Devices : 4 Total Devices : 4 Persistence : Superblock is persistent Intent Bitmap : Internal Update Time : Sat Jan 13 23:30:41 2018 State : active Active Devices : 4 Working Devices : 4 Failed Devices : 0 Spare Devices : 0ve výpisu disků
Disk /dev/md126: 7471.3 GB, 7471290974208 bytes, 14592365184 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 65536 bytes / 196608 bytesnad ním je LUKS a ve výpisu dá.
Disk /dev/mapper/uloziste: 7471.3 GB, 7471289401344 bytes, 14592362112 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 65536 bytes / 196608 bytesa nad ním je file system
df Filesystem 1K-blocks Used Available Use% Mounted on /dev/mapper/uloziste 7238526024 4276218324 2960832080 60% /mnt/basicTohle z prvního pohledu vypadá dobře. Ale ten rozpor, který mám, a na který se chci zeptat, je v obsazeném prostoru. FS zabírá pře 4TB (což jsem nakopíroval a je správně) zatímco RAID pole pod LUKSem považuje za obsazené pouze 2,4TB a v zásadě se žádnými operacemi nad FS tato hodnota nemění. Takže mi není jasné, jak je to se synchronizacía konzistencí pole. pokud to nepovažuje za obsazené, tak to nebude přece synchronizovat. A proč si to myslí. Všechno mám zatím i jinde takže celé pole se může postavit znovu, ale nerozumím, proč se obsazení nepropisuje dolů.
FS zabírá pře 4TBNe, FS zabírá 7.41 TB (size v df + nejspíš nějaké drobné na metadata).
zatímco RAID pole pod LUKSem považuje za obsazené pouze 2,4TBUkazuje to obsazené 2.49 TB na každém disku * 3 disky (4. je paritní) = 7.47 TB, což je stejné jako ta velikost FS.
a v zásadě se žádnými operacemi nad FS tato hodnota neměníMD nevidí to dat, která jsou nad ním a synchronizace se řeší pouze write-intent bitmapou.
Tiskni Sdílej: