Dotaz: Velká fragmentace sparse files na ocfs2 nad drbd

[majales]

V jednom řešení pro virtualizaci většího počtu serverů používáme ocfs2 nad drbd. Mount ocfs2 je ve fstab takto

UUID=7ea9b285-1644-43fe-97fg-53d02f890fcb  /var/lib/libvirt    ocfs2  _netdev,x-systemd.requires=o2cb.service  0   0

debugfs.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: 65535

filesysté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 myocfs2

Problé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?

Odpovědi

[Want]

Kontroluješ to drbd?

[majales]

Drbd je v pořádku, ale podle mě to s ocfs2 filesystémem co dělat.

[Want]

Jseš si nějak moc jistý. Ocfs2 je pouze nadstavba nad ext3, která hlídá to, aby při použití z více strojů nedocházelo k nekonzistenci. Drbd ti v podstatě nahrazuje MD raid.

[majales]

Zkoušel jsem k tomu něco najít, ale souvislost fragmentace ocfs2 s drbd jsem nikde nenašel. @Want Můžete mi to prosím vysvětlit, jestli o tom více něco víc? DRBD mám a funguje normálně přes 10GB interface a je syncnutý. Našel jsem jen radu o tom jak vytvářet ofcs2 fs pro podobná řešení s drbd a qcow2 a v podstatě navrhují zdesetinásobit počet "inodů" při vytváření fs. Vím, že můžu udělat offline defragmentaci ocfs2, ale ještě jsem to pořádně nevyzkoušel. Ty qcow2 soubory, které jsem zkoušel defragemntovat nijak zvlášť svou fragmentaci nezměnili..

[Want]

Pro mne je to už dávno uzavřená kapitola. Mám spolehlivější řešení. Ale čas od času se to rozpadalo.

[Want]

To DRBD. Spolehlivější byl sheepdog, ale vývoj skončil a od roku 2012 jedu všechno diskless přes NFS, které je mnohem spolehlivější.

[carbon]

mno ja teda nevim, ocfs neznam, ale "Feature Incompat: ... sparse ..." to jedes nejakou starou verzi? man

[majales]

Mě to taky Incompat: přišlo taky divný, ale studoval jsem to už předtím z manuálových stránek mi přijde, že je to v pořádku:

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

[Want]

Možná jsem něco přehlédnul, ale nikde tu nevidím výpisy stavu toho drbd na jednotlivých nodech.

[Max]

drbd může být člověku putna, ne? Řešíš jinou vrstvu.
Zdar Max

[Want]

Putna? Si děláš srandu? Ocfs2 je pouze FS, který umožňuje práci s jedním blokovým zařízením z více nodů. O replikaci dat se stará DRBD.

[xxl]

DRBD vytváří raid1 mezi blokovými zařízeními, která jsou umístěná na různých nodech/počítačích. Co si NAD něj dáš za filesystém, je mu srdečně jedno.

[Aleš Kapica]

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.

[majales]

Znovu píšu a opakuji se .. DRBD je v pořádku. A není mi jasná souvislost stavi DRBD s fragmentací ocfs2. Kdyžtak mi to prosím vysvětlete. Jestli vám chybí stav DRBD tak tohle snad uspokojí pana Kapicu i anonyma jménem carbon.

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í.

[Aleš Kapica]

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ší.

[Aleš Kapica]

Mimochodem není jedno, jestli je to clusterový FS nebo ne.

[xxl]

Njn, záleží na celkové konfiguraci, kterou neznáme.

[Max]

Ano, putna, když řeší fragmentaci FS, tak je fakt jedno, co pod tím je. Ta fragmnetace je věcí toho fs a drbd s tím nemá nic společného.
Zdar Max

[Aleš Kapica]

A kde bereš tu jistotu, že mu to nerozbíjí to DRBD co je pod tím?

[Max]

Jak by mohlo drbd, které se chová jako blokové zařízení za to, že FS nad tím hodně fragmentuje? Samo drbd by sice mohlo fragmentovat, ale to ten FS nad tím nijak nepozná, ten řeší jen svojí vrstvu.
Jinak já v tom nevidím východisko. Online defrag je sice možný, ale není doporučován pro používané soubory. Jakmile se soubor používáš, tak bude docházet k lockům a defragmentace i výkon aplikace půjde do zádele. V tomto případě tedy výkon VM.

Linux prostě nemá slušnou alternativu pro VMFS od VMware. Sdílený blokový storage je prostě pain. Proxmox na to má i matrix. S kvm dává smysl tedy jen několik variant, ale každá má nějaké omezení. Smysl asi dává LVM-thick, ale zase člověk musí oželet snapshoty.
Jinak řečeno, jedině NFS, nebo pak něco monstr jeko ceph.
Zdar Max

[Aleš Kapica]

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.

[Max]

To mi přijde jako nesmysl. Je to jako tvrdit, že fragmentaci třeba u ext4 může firmware disku. Jsou to dvě rozdílné vrstvy.
A kdyby drbd nestíhalo syncovat, tak by to mělo za následek snížení výkonu.

Ceph je asi dnes bezkonkurenční, jelikož kompatibilita, stabilita, robustnost, napojení na kontejnerizaci, S3 storage apod. Jen to chce a to infra / hw.
My jedeme sdílený blokový storage, je to pekelně rychlý, hypervisory přes iSCSI, ale vmware, no. Když bychom chtěli migrovat na Proxmox, což u pár věcí už migrujeme, tak je to pain. Zatím tedy řešíme u standalone storage řešení.
Nyní jsme před nákupem nového HA storage, takže je otázkou, do čeho jít. Když on ten HPE Nimble je fakt dobrej, jen škoda, že nemá NFS, jen blokové zařízení v podobě iSCSI a FC. Mají řešení i pro persistentní k8s storage, ale je to šílená drbárna se spoustou míst, kde se něco může podělat a je to pak blbě diagnostikovatelná černá díra.
Zdar Max

[Aleš Kapica]

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.

[Max]

Pokud vím, to samé by mělo umět zfs.

Nerozumím. Jestli myslíš iscsi export, tak ano, ale nechápu souvislost.
Zdar Max

[Aleš Kapica]

Ano. Měl jsem na mysli export blokového zařízení přes iSCSI. Pak by problémy tohoto typu neměly vznikat. Toť k souvislosti.

[Max]

Jaký problém? Problém sdíleného blokového zařízení u Linuxu? To si jen myslíš, protože ti ten matrix, co jsem linkoval, přijde super zelený :D. Ale to jen do té doby, než zjistíš, co tím autor myslel.
Jinými slovy, je to stejné jako u jiného iSCSI. Když chceš mít sdílený prostor, tak co disk, to lun. A když máš 200 mašin a každá třeba 2 disky, tak máš 400 lunů. Super řešení :D.
Proxmox to automatizuje tak, že se na ten storage přihlásí přes ssh a ten lun za tebe vytvoří (což zní fakt spolehlivě a bezpečně :D).
Stejně tak to můžeš udělat s jiným storage, co poskytuje iSCSI, jen to musíš klikat ručně.
Snapshoty to neřeší, ty to řeší na úrovni storage, nikoli VM.

Jak jsem psal, NFS, nebo Ceph, všechno ostatní je pain.
Zdar Max

[majales]

Abych to celé objasnil celá konfigurace je následující MD array=>DRBD=>LVM=>iSCSI přimountované jako iSCSI a je na tom ocfs2 fs. Bohužel fragmentované je to pořád. FS je vytvořen s parametrem "-T vmstore". Někde jsem viděl doporučení, při vytváření ocfs2 pro qcow2 thin (sparse) souborů kde se manuálně nastavoval počet "inodů" na fs na 10x větší hodnotu než při vytvoření pomocí toho partametru vmstore. U většiny VM strojů je přenastavený fstrim pomocí override.conf takto:

[Timer]
OnCalendar=daily
AccuracySec=1h
Persistent=true
RandomizedDelaySec=3600