Jakub Vrána napsal AI plugin sql-gemini pro nástroj pro správu databáze v jednom PHP souboru Adminer. Plugin dovoluje sestavovat SQL dotazy pomocí AI, konkrétně pomocí Google Gemini.
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.
Byla vydána nová verze 0.4.15 (𝕏) svobodného operačního systému ReactOS (Wikipedie), jehož cílem je kompletní binární kompatibilita s aplikacemi a ovladači pro Windows. Přehled novinek i s náhledy v oznámení o vydání.
Byl představen rpi-image-gen, tj. oficiální nástroj pro vytváření vlastních softwarových obrazů pro zařízení Raspberry Pi.
Byla vydána nová major verze 8.0, aktuálně 8.0.1, softwaru pro správu elektronických knih Calibre (Wikipedie). Přehled novinek v poznámkách k vydání. Vypíchnuta je lepší podpora Kobo KEPUB formátu nebo integrovaný lokálně běžící engine Piper pro převod textu na řeč používaný pro čtení nahlas (již od verze 7.18).
Společnost OpenAI rozšířila své API o nové audio modely. Nový model pro převod textu na řeč (text-to-speech model) lze bez přihlašování vyzkoušet na stránce OpenAI.fm.
Příspěvek Bezpečnost paměti pro webové fonty na blogu Chrome pro vývojáře rozebírá, proč se pro zpracování webových fontů v Chrome místo FreeType nově používá v Rustu napsaná Skrifa z Fontations.
V pátek 21. a v sobotu 22. března proběhnou Arduino Days 2025, tj. každoroční „narozeninová oslava“ platformy Arduino. Na programu je řada zajímavých přednášek. Sledovat je bude možné na YouTube. Zúčastnit se lze i lokálních akcí. V sobotu v Praze na Matfyzu.
Komunitná konferencia Bratislava OpenCamp, ktorá sa uskutoční už o tri týždne 5. 4. 2025 na FIIT STU pozná svoj program – návštevníkom ponúkne 3 paralelné behy prednášok a workshopov na rôzne témy týkajúce sa otvoreného softvéru či otvorených technológií.
Časopis MagPi od nakladatelství Raspberry Pi se s číslem 151 přejmenoval na Raspberry Pi Official Magazine. I pod novým názvem zůstává nadále ve formátu pdf zdarma ke čtení.
UUID=7ea9b285-1644-43fe-97fg-53d02f890fcb /var/lib/libvirt ocfs2 _netdev,x-systemd.requires=o2cb.service 0 0debugfs.ocfs2 -n -R "stats" /dev/sda ukazuje toto:
debugfs.ocfs2 -n -R "stats" /dev/sda Revision: 0.90 Mount Count: 0 Max Mount Count: 20 State: 0 Errors: 0 Check Interval: 0 Last Check: Wed Feb 9 11:04:59 2022 Creator OS: 0 Feature Compat: 3 backup-super strict-journal-super Feature Incompat: 63312 sparse extended-slotmap inline-data xattr indexed-dirs refcount discontig-bg clusterinfo append-dio Tunefs Incomplete: 0 Feature RO compat: 1 unwritten Root Blknum: 257 System Dir Blknum: 258 First Cluster Group Blknum: 128 Block Size Bits: 12 Cluster Size Bits: 19 Max Node Slots: 8 Extended Attributes Inline Size: 256 Label: myocfs2 UUID: 7EA9B285164443FE97FD55D02F890FCB Hash: 3171869824 (0xbd0ee480) DX Seeds: 2371934283 2135051716 2982105244 (0x8d60d84b 0x7f424dc4 0xb1bf509c) Cluster stack: o2cb Cluster name: kvmcluster Cluster flags: 1 Globalheartbeat Inode: 2 Mode: 00 Generation: 3594742897 (0xd6436c71) FS Generation: 3594742897 (0xd6436c71) CRC32: 00000000 ECC: 0000 Type: Unknown Attr: 0x0 Flags: Valid System Superblock Dynamic Features: (0x0) User: 0 (root) Group: 0 (root) Size: 0 Links: 0 Clusters: 2805674 ctime: 0x620391cb 0x0 -- Wed Feb 9 11:04:59.0 2022 atime: 0x0 0x0 -- Thu Jan 1 01:00:00.0 1970 mtime: 0x620391cb 0x0 -- Wed Feb 9 11:04:59.0 2022 dtime: 0x0 -- Thu Jan 1 01:00:00 1970 Refcount Block: 0 Last Extblk: 0 Orphan Slot: 0 Sub Alloc Slot: Global Sub Alloc Bit: 65535filesystém byl vytvořen takto:
o2info --mkfs /dev/sda -N 8 -J size=134217728 -b 4096 -C 524288 --fs-features backup-super,strict-journal-super,sparse,extended-slotmap,inline-data,xattr,indexed-dirs,refcount,discontig-bg,clusterinfo,append-dio,unwritten -L myocfs2Problém je ve fragmentaci souborů a podle mě v nesprávném fungování ocfs2 se sparse files. 200GB qcow2 sparse soubor který využívá jedna z virtuálek má podle filefrag 81604 extentů, a při o něco více než 200 souborů na ocfs2 je vyčerpáno 70% inodů z celkových 2805674. Netuší někdo co je špatně s tímto nastavením?
FEATURE FLAGS The feature flags are split into three categories, namely, Compat, Incompat and RO Compat. Compat, or compatible, is a feature that the file system does not need to fully understand to safely read/write to the volume. An example of this is the backup-super feature that added the capability to backup the super block in multiple locations in the file system. As the backup super blocks are typically not read nor written to by the file system, an older file system can safely mount a volume with this feature enabled. Incompat, or incompatible, is a feature that the file system needs to fully understand to read/write to the volume. Most features fall under this category. RO Compat, or read-only compatible, is a feature that the file system needs to fully understand to write to the volume. Older software can safely read a volume with this feature enabled. An example of this would be user and group quotas. As quotas are manipulated only when the file system is written to, older software can safely mount such volumes in read-only mode.Dále posílám ostatní výpisy z o2info
o2info --volinfo /dev/sda Label: myocfs2 UUID: 7EA9B285164443FE97FD55D02F890FCB Block Size: 4096 Cluster Size: 524288 Node Slots: 8 Features: backup-super strict-journal-super sparse extended-slotmap Features: inline-data xattr indexed-dirs refcount discontig-bg clusterinfo Features: append-dio unwritten
o2info --freeinode /dev/sda Slot Space Free 0 1024 341 1 1024 834 2 0 0 3 0 0 4 0 0 5 0 0 6 0 0 7 0 0 Total 2048 1175
o2info --freefrag 524288 /dev/sda Blocksize: 4096 bytes Clustersize: 524288 bytes Total clusters: 2805674 Free clusters: 870536 (31.0%) Min. free extent: 512 KB Max. free extent: 15872 KB Avg. free extent: 2048 KB Chunksize: 536870912 bytes (1024 clusters) Total chunks: 2740 Free chunks: 0 (0.0%) HISTOGRAM OF FREE EXTENT SIZES: Extent Size Range : Free extents Free Clusters Percent 512K... 1024K- : 61251 61251 7.04% 1M... 2M- : 46362 110734 12.72% 2M... 4M- : 43332 230561 26.48% 4M... 8M- : 30888 335973 38.59% 8M... 16M- : 6083 132017 15.17%
o2info --filestat /var/lib/libvirt/images/ File: /var/lib/libvirt/images/ Size: 3896 Blocks: 8 IO Block: 4096 directory Device: 800h/2048d Inode: 8257681 Links: 5 Frag%: 0.00 Clusters: 0 Extents: 1 Score: 0 Shared: 0 Unwritten: 0 Holes: 0 Xattr: 0 Access: (0750/drwxr-x---) Uid: (64055/libvirt-qemu) Gid: (64055/libvirt-qemu) Access: 2025-03-10 23:52:32.800091216 +0100 Modify: 2025-03-11 02:05:20.30629001 Change: 2025-03-11 02:05:20.30629001
A zaregistroval jsi na co hledá odpověď tazatel? Co mu brání v tom aby sem předhodil výpis v jakém stavu se nalézá DRBD na jednotlivých nodech? Co když ho má rozbité a je potřebná nová synchronizace? To je problém, který mu OCFS2 nevyřeší, jenom oznámí. Stejně jako to oznamuje Btrfs, když je problém na úrovni blokového zařízení.
Anonym carbon se tady pozastavil nad tím, že je to ocfs2 nějaká starší verze a co když má stejný problém i na úrovni DRBD? Nikdo z nás křišťálovou kouli nemá, a bez toho že by sem nakopíroval co mu vrací cat /proc/drbd
mu k tomu jen těžko něco říct.
cat /proc/drbd version: 8.4.11 (api:1/proto:86-101) srcversion: 7BCC4D94102468D91B111BE 0: cs:Connected ro:Primary/Primary ds:UpToDate/UpToDate C r----- ns:97212568 nr:530075522 dw:71345274 dr:1350218603 al:22900 bm:0 lo:0 pe:0 ua:1 ap:0 ep:1 wo:f oos:0 1: cs:Connected ro:Secondary/Primary ds:UpToDate/UpToDate C r----- ns:0 nr:1115165024 dw:1115165024 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:d oos:0
apt list --installed |grep ocfs WARNING: apt does not have a stable CLI interface. Use with caution in scripts. ocfs2-tools/oldstable,now 1.8.6-6 amd64 [instalovaný]Je tohle pro vás stará verze? Chápu, že není nejnovější, ale zase nějaká ultra stará verze to není.
Tak o mé uspokojení tady zrovna nejde. Podle toho výpisu z blíže neurčeného nodu existují dvě drbd bloková zařízení. Předpokládám že to nad kterým je to ocfs2 je /dev/drbd0
, takže mi nějak nesedí to /dev/sda
u toho ocfs2. A co ta druhá strana? Taky ok? Každopádně bych na to zařízení nejprve pustil verifikaci a teprve pak řešil ocfs2. A pokud jde o sparse soubory, tak qcow2 mi na tohle nepřijde jako ta nejlepší volba, jelikož jde o další vrstvu. Použití raw souboru bylo spolehlivější.
Jak by mohlo drbd, které se chová jako blokové zařízení za to, že FS nad tím hodně fragmentuje?
Úplně jednoduše. Tím, že z druhé strany přenáší datové bloky tam kde nemají být. Ocfs2 je clusterový systém, který komunikuje nezávisle na DRBD a to pokud je to v režimu MASTER-MASTER přenáší data oběma směry. Pro DRBD jsou to jen data, která žádným způsobem nekontroluje, pouze replikuje. A když jsou na straně B blbosti, může jejich replikace mít tenhle efekt na straně A – prokud ocfs2 nestíhá obsluhovat obě strany rychleji než drbd.
Dnes už nikde sdílený blokový storage nepoužívám. Je to zbytečné. Ale tenkrát jsem raději přešel na režim MASTER-SLAVE a použil Btrfs. Volba na Btrfs padla proto, že se uživatelské účty snapshotovaly a ty snapshoty se odsypávaly na lokální disk stroje, který byl zrovna v roli MASTER.
Jinak Sheepdog byl pro distribované blokové zařízení lepší než Ceph. V principu fungoval velice podobně jako Btrfs, proto si také velmi dobře s Btrfs rozumněl. Na rozdíl od Cephu mu k bezvýpadkovému přežití stačil jeden nod. Jeho slabinou byla závislost na corosyncu, který rozumně funguje tak do 16 nodů. Bylo možné použít i zookeeper, který jich zvládal přes 250, jenže ten už je taky pasé.
Používal jsem před ním i GlusterFS. Ale pak se pořídil Netapp, o stroje co jsem dřív používal se rozšířil Ceph, protože k zajištění infrastruktury stačí pouze jeden virtualizační stroj, který na ty data leze přes NFS.
My jedeme sdílený blokový storage, je to pekelně rychlý, hypervisory přes iSCSI, ale vmware, no.
Pokud vím, to samé by mělo umět zfs.
Nyní jsme před nákupem nového HA storage, takže je otázkou, do čeho jít.
No. Nezávidím. Přijde mi, že s nástupem čmoudů vývoj opensource HA dosti upadnul. Nelijou se do toho prachy, nejsou lidi, není vůle. Je to jak s tím sheepdogem. Bylo (podle mne) lepší řešení, ale vývoj probíhal jen do té doby, co mitake dělal v oboru. Přitom mi přije jeho idea mnohem nosnější – vycházel z toho, že živelná pohroma na čas přeruší spojení mezi úložišti v různých lokacích a šlo o to, aby stroje přežily v běhu do obnovení konektivity. Jako primár se tedy brala ta verze, která zůstala v běhu. A replikace dat byla ta první věc co se děla po obnovení spojení. Bylo to jednoduché. Vše v rámci nodu řešil pouze jeden klient. A přes jaderný modul to bylo možné namountovat i lokálně. Ten corosync (resp. zookeeper) sloužil jen k tomu aby podával zprávu o tom co žije. No ale asi to nebyl takový byznys.
[Timer] OnCalendar=daily AccuracySec=1h Persistent=true RandomizedDelaySec=3600
Tiskni
Sdílej: