Fórum Root.cz
Hlavní témata => Software => Téma založeno: RDa 25. 07. 2025, 15:00:52
-
Ahoj, mám pole z 8x 14TB disků v BTRFS RAID-6 režimu, tj. 84TB využitelného místa.
Ve stavu kdy bylo volné místo hlášeno jako 131 GB se to remountlo do RO - kvůli "chybě" - prý došlo místo.
Pak jsem chvíli zápasil to rychle zprovoznit (různé logování mám přesměrováno taky na tenhle storage a hlásilo to co minutu nemožnost zápisu) ... remount,rw nešlo - prý je FS v nekonzistentním stavu či má chybu.. takže jsem to musel odmountovat, odmountovat všechny bind mounty a vypnout NFS. A pak remountnout s pár volbama navíc, aby to bylo zas v RW a mohl jsem tam smazat pár stovek GB a vyřešit tím nouzi.
dmesg panic:
[24691097.702274] ------------[ cut here ]------------
[24691097.702280] BTRFS: Transaction aborted (error -28)
[24691097.702326] WARNING: CPU: 16 PID: 8114 at fs/btrfs/free-space-tree.c:865 remove_from_free_space_tree+0x13f/0x150 [btrfs]
[24691097.702478] Modules linked in: exfat ntfs3 rpcsec_gss_krb5 nfsv4 btrfs dm_crypt nfsd auth_rpcgss nfs_acl nfs lockd grace netfs sunrpc ipmi_ssif skx_edac skx_edac_common x86_pkg_temp_thermal coretemp kvm_intel mlx4_ib i2c_i801 ib_uverbs i2c_smbus input_leds mei_me mei acpi_power_meter ipmi_si acpi_ipmi ipmi_devintf ipmi_msghandler efivarfs ixgbe xfrm_algo megaraid_sas
[24691097.702539] CPU: 16 UID: 0 PID: 8114 Comm: btrfs-transacti Not tainted 6.11.0-gentoo-x86_64 #5
[24691097.702547] Hardware name: Supermicro Super Server/X11SPL-F, BIOS 3.9 03/15/2023
[24691097.702550] RIP: 0010:remove_from_free_space_tree+0x13f/0x150 [btrfs]
[24691097.702675] Code: ff ff ff e8 c3 2f f4 ff eb 8e 4c 89 ef bd fe ff ff ff e8 b4 2f f4 ff e9 7c ff ff ff 89 ee 48 c7 c7 d8 aa 92 c0 e8 91 6a 92 f0 <0f> 0b eb c6 66 66 2e 0f 1f 84 00 00 00 00 00 66 90 90 90 90 90 90
[24691097.702681] RSP: 0018:ffffb89342767c80 EFLAGS: 00010282
[24691097.702686] RAX: 0000000000000000 RBX: ffff98da12df98f0 RCX: 0000000000000000
[24691097.702691] RDX: 0000000000000002 RSI: 0000000000000027 RDI: 00000000ffffffff
[24691097.702695] RBP: 00000000ffffffe4 R08: 00000001017914bb R09: 0000000000000001
[24691097.702698] R10: 00000001017914bb R11: ffff98f8fe800000 R12: 0000000000004000
[24691097.702702] R13: ffff98ea8a3f0b60 R14: ffff98da3f1bd400 R15: ffff98da3f1bd5e0
[24691097.702705] FS: 0000000000000000(0000) GS:ffff98f8ffe00000(0000) knlGS:0000000000000000
[24691097.702710] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[24691097.702714] CR2: 00007ff570b240d0 CR3: 0000000c3e248001 CR4: 00000000007706f0
[24691097.702717] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[24691097.702720] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[24691097.702723] PKRU: 55555554
[24691097.702726] Call Trace:
[24691097.702731] <TASK>
[24691097.702736] ? __warn+0x7c/0x120
[24691097.702749] ? remove_from_free_space_tree+0x13f/0x150 [btrfs]
[24691097.702872] ? report_bug+0x18d/0x1c0
[24691097.702881] ? handle_bug+0x3a/0x70
[24691097.702889] ? exc_invalid_op+0x13/0x60
[24691097.702896] ? asm_exc_invalid_op+0x16/0x20
[24691097.702910] ? remove_from_free_space_tree+0x13f/0x150 [btrfs]
[24691097.703034] alloc_reserved_extent+0x1f/0xd0 [btrfs]
[24691097.703140] __btrfs_run_delayed_refs+0xb04/0x1070 [btrfs]
[24691097.703252] btrfs_run_delayed_refs+0x5d/0x110 [btrfs]
[24691097.703359] btrfs_commit_transaction+0x5c7/0xe20 [btrfs]
[24691097.703489] ? start_transaction+0xc0/0x840 [btrfs]
[24691097.703610] transaction_kthread+0x155/0x1c0 [btrfs]
[24691097.703728] ? __pfx_transaction_kthread+0x10/0x10 [btrfs]
[24691097.703844] kthread+0xda/0x110
[24691097.703853] ? __pfx_kthread+0x10/0x10
[24691097.703860] ret_from_fork+0x2d/0x50
[24691097.703866] ? __pfx_kthread+0x10/0x10
[24691097.703873] ret_from_fork_asm+0x1a/0x30
[24691097.703883] </TASK>
[24691097.703885] ---[ end trace 0000000000000000 ]---
a samotný BTRFS v dmesg dopsal tohle:
[24691097.703890] BTRFS info (device dm-1 state A): dumping space info:
[24691097.703896] BTRFS info (device dm-1 state A): space_info DATA has 131499511808 free, is full
[24691097.703901] BTRFS info (device dm-1 state A): space_info total=83864976359424, used=83733476028416, pinned=28672, reserved=0, may_use=4096, readonly=786432 zone_unusable=0
[24691097.703909] BTRFS info (device dm-1 state A): space_info METADATA has 0 free, is full
[24691097.703913] BTRFS info (device dm-1 state A): space_info total=138110042112, used=136951889920, pinned=1140146176, reserved=17219584, may_use=0, readonly=786432 zone_unusable=0
[24691097.703920] BTRFS info (device dm-1 state A): space_info SYSTEM has 8159232 free, is not full
[24691097.703924] BTRFS info (device dm-1 state A): space_info total=12582912, used=4423680, pinned=0, reserved=0, may_use=0, readonly=0 zone_unusable=0
[24691097.703930] BTRFS info (device dm-1 state A): global_block_rsv: size 536870912 reserved 0
[24691097.703934] BTRFS info (device dm-1 state A): trans_block_rsv: size 0 reserved 0
[24691097.703937] BTRFS info (device dm-1 state A): chunk_block_rsv: size 0 reserved 0
[24691097.703940] BTRFS info (device dm-1 state A): delayed_block_rsv: size 0 reserved 0
[24691097.703944] BTRFS info (device dm-1 state A): delayed_refs_rsv: size 988413952 reserved 0
[24691097.703948] BTRFS: error (device dm-1 state A) in remove_from_free_space_tree:865: errno=-28 No space left
[24691097.703954] BTRFS info (device dm-1 state EA): forced readonly
[24691097.703962] BTRFS error (device dm-1 state EA): failed to run delayed ref for logical 6309443567616 num_bytes 16384 type 176 action 1 ref_mod 1: -28
[24691097.703971] BTRFS: error (device dm-1 state EA) in btrfs_run_delayed_refs:2199: errno=-28 No space left
[24691097.703977] BTRFS warning (device dm-1 state EA): Skipping commit of aborted transaction.
[24691097.703981] BTRFS: error (device dm-1 state EA) in cleanup_transaction:2018: errno=-28 No space left
mount -o remount,rw ... nedopadl. Takže jsem musel zastavit vše co tam šahalo a dát umount:
[24691687.760428] BTRFS error (device dm-1 state EMA): remounting read-write after error is not allowed
[24692290.779067] BTRFS info (device dm-1 state EA): last unmount of filesystem 88be0937-6cfe-4208-b838-058a1c989367
[24692304.008806] BTRFS info (device dm-1): first mount of filesystem 88be0937-6cfe-4208-b838-058a1c989367
[24692304.008843] BTRFS info (device dm-1): using crc32c (crc32c-intel) checksum algorithm
[24692304.008851] BTRFS info (device dm-1): using free-space-tree
[24692393.382389] BTRFS info (device dm-1): rebuilding free space tree
Je to nějaká chyba v BTRFS (kernel zde je 6.11.0) - nebo proč si to nedokázalo zvětšit metadata region?
Dá se tomu při mkfs říct, že chci více metadat ? Ono to btrfs je celkem divný v tom, že neoznamuje počet a využití inodes (tak jsem předpokládal, že si to dokáže řešit sám dynamicky).
Ale stejně.. wtf je "space_info DATA has 131499511808 free, is full" ?
Jsem nečekal, že produkční FS v mainline bude házet kernel panic, jen proto, že jsem disk zaplnil způsobem, jaký asi autoři nečekali :D
A teď jak jsem chtěl napsat kolik je tam souborů - skrze "find . | grep -n .", tak stovky GB volného místa zmizelo - aplikace tam zapisující hlásí no free space a zápis nejde - skrze "watch -n 1 df -H" vidím různě problikávat dvě varianty stavu:
113T 84T 0 100% /mnt/****
↕
113T 84T 909G 100% /mnt/****
WTF, co se to děje na tom FS ?
Ctrl+Z pro ten find, smažu/přesunu film s 10GB .. objeví se 917G volného místa, fg .. find pokračuje a za vteřinu volné místo 0. To fakt nechápu co to jako dělá. A proč RO úloha jako find - procházení adresářů, má vůbec vliv na volné místo.
Když sleduji odsun souborů - tak místo v "df" narůstá po cca 10GB jak je velikost těch souborů, ale tady se nic nemění - ani během odsunu, ani během běhu find příkazu. Přitom po odsunu volné místo je a zápis logů probíhá.. ale jakmile pustím find.. tak df hlásí nulu a zápisy nejdou. Neskutečný bordel.
btrfs fi df /mnt/****
Data, RAID6: total=76.27TiB, used=75.42TiB
System, RAID6: total=12.00MiB, used=4.22MiB
Metadata, RAID6: total=134.62GiB, used=134.11GiB
GlobalReserve, single: total=512.00MiB, used=0.00B
(podle starého uloženého indexu by tam mělo být 43M souborů)
Tak ještě koukám na: btrfs fil usage /mnt/****
Overall:
Device size: 101.87TiB
Device allocated: 101.87TiB
Device unallocated: 8.00MiB
Device missing: 0.00B
Device slack: 0.00B
Used: 100.70TiB
Free (estimated): 892.56GiB (min: 892.56GiB)
Free (statfs, df): 0.00B
Data ratio: 1.33
Metadata ratio: 1.33
Global reserve: 512.00MiB (used: 0.00B)
Multiple profiles: no
Data,RAID6: Size:76.27TiB, Used:75.40TiB (98.86%)
~
Metadata,RAID6: Size:134.62GiB, Used:134.12GiB (99.63%)
~
System,RAID6: Size:12.00MiB, Used:4.22MiB (35.16%)
~
A přijde mi, že mu schází místo v metadatech, a nemůže se alokovat žádnej další 1GB chunk pro ně.. protože tam je vše zabrané datovýmy chunky... které se z nějakého důvodu neuvolňují.
Takže zkusím: btrfs balance start -v -dusage=10 /mnt/****
Dumping filters: flags 0x1, state 0x0, force is off
DATA (flags 0x2): balancing, usage=10
ERROR: error during balancing '/mnt/****/': No space left on device
There may be more info in syslog - try dmesg | tail
Tak to je další WTF.. nemůže to uvolnit místo, protože "není" volné místo :D .... Hlava XXII.
Mažu další soubory a "uvolňuji" desítky GB, find je pořád pozastaven.
Rebalance (s dusage=10) znova.. už to jede a dmesg se plní realokacema.. a volné chunky rostou. Konečně!
Tak jsem se posunul z
Overall:
Device size: 101.87TiB
Device allocated: 101.87TiB
Device unallocated: 8.00MiB
Device missing: 0.00B
Device slack: 0.00B
Used: 100.68TiB
Free (estimated): 909.33GiB (min: 909.33GiB)
Free (statfs, df): 909.33GiB
Data ratio: 1.33
Metadata ratio: 1.33
Global reserve: 512.00MiB (used: 0.00B)
Multiple profiles: no
na
Overall:
Device size: 101.87TiB
Device allocated: 101.12TiB
Device unallocated: 767.06GiB
Device missing: 0.00B
Device slack: 0.00B
Used: 100.68TiB
Free (estimated): 909.38GiB (min: 909.38GiB)
Free (statfs, df): 909.38GiB
Data ratio: 1.33
Metadata ratio: 1.33
Global reserve: 512.00MiB (used: 0.00B)
Multiple profiles: no
a find nechal dojet - a naplnil se předpoklad, že procházení/čtení konzumuje místo!!, viz stav před/po:
Metadata,RAID6: Size:134.62GiB, Used:133.98GiB (99.52%)
↓
Metadata,RAID6: Size:142.88GiB, Used:142.19GiB (99.52%)
To je peklo s tím COW, že to potřebuje takovy "vacuum" jak pg ... a nikdo se o tom pořádně nezmiňuje ať si ten rebalance přidáš do cronu !
Ale asi pořád lepší to mít pod kontrolou, než aby uklízečka jela v kthreadu a řádila kdy to člověk nečeká a např. manipuluje s disky.
Na druhou stranu.. v případě, že alokace došla na konec, tak by měl proběhnout automatický rebalance pro získání alepoň jednoho volného chunku.. a to se neděje. Raději bych těch 10-20 sec IO latence přežil.. než -ENOSP, nebo nedejbože broken flag + RO.
Anketa.. kdo máte BTRFS a víte o nutnosti rebalance (defakto defragmentace a vacuuming) - a kdo ho v cronu i máte - nebo jste ještě nedošli na konec volného místa ?
PS. Snapshoty v této sérii problémů nehrají roli (mazaná data nejsou uzamčená snapshotem)
PS2. Je tam 42.288.071 souborů.
-
V manualu maji k RAIDu 6 "the feature should not be used in production, only for evaluation or testing" a "Do not use raid5 nor raid6 for metadata. Use raid1 or raid1c3 respectively." (https://btrfs.readthedocs.io/en/latest/btrfs-man5.html#raid56-status-and-recommended-practices).
Predpokladam tedy, ze jde porad o nestabilni featuru.
Sam mam btrfs na datovem disku, ale pod nim je lvm a mdraid6. Posledni dobou je ten filesystem dost liny, takze me asi ceka "vyplivnuti bokem a znovunahrani". Rebalance/defrag jsem nedavno delal a vykonu to nepomohlo.
-
V manualu maji k RAIDu 6 "the feature should not be used in production, only for evaluation or testing" a "Do not use raid5 nor raid6 for metadata. Use raid1 or raid1c3 respectively." (https://btrfs.readthedocs.io/en/latest/btrfs-man5.html#raid56-status-and-recommended-practices).
Predpokladam tedy, ze jde porad o nestabilni featuru.
Tak ja bych rad presunul metadata na nejaky dedikovany SSD raid do mirroru - ale mainline implementace to jeste neumi.
Nedavno (2025/05) se resil urcity patch, ale nebylo to uplne cisty.. treba tento komentar navrhuje hezci reseni (a souhlasim s tim):
https://lore.kernel.org/linux-btrfs/aC6jEehifdWWq4Pq@hungrycats.org/
Ale dik za upozorneni.. dam to zmigrovat alespon tedy na raid1c3 - tj. ochrana proti vypadku dvou disku).
Sam mam btrfs na datovem disku, ale pod nim je lvm a mdraid6. Posledni dobou je ten filesystem dost liny, takze me asi ceka "vyplivnuti bokem a znovunahrani". Rebalance/defrag jsem nedavno delal a vykonu to nepomohlo.
Na prvni pohled se mi zda ze po tom rebalance se to chova lepe.. svizneji.
Predtim to neskutecne chroustalo pro kazdej soubor a zapis velkych dat jel tak 10-15 MB/s.
Nejdelsi run bylo dostat tech 800G s dusage=10 zpet, nasledne behy rebalance az po dusage=80 byl zlomek casu.
-
Podle toho, co jsem četl, se btrfs raid5 i raid6 dají používat pro data, ale ne pro metadata. Metadata bys měl mít raid1c3. Pak je to prý spolehlivé i dlouhodobě. Najdi si například příspěvky Andreje na abclinuxu.cz.
-
a nechavat to zaplnit na 99% to taky neni dobre
All filesystems for best performance should have some minimum percentage of free space, usally 5-10%. Btrfs, using a two-level space manager (chunks and blocks within chunks) plus being based on (nearly) copy-on-write, benefits from more space to be kept free, around 10-15%, and in particular from having at least one or a few chunks fully unallocated.
-
a nechavat to zaplnit na 99% to taky neni dobre
Koupil jsem si 14TB, chci si tam ulozit 14TB !
(s rezii FS pocitam - ale s overprovisioningem kvuli marnemu kodu nikoliv.. to se vracime do doby, kdy RAM nesla defragmentovat bez toho, aniz aby mel clovek i nejaky malej SWAP partition)
All filesystems for best performance should have some minimum percentage of free space, usally 5-10%. Btrfs, using a two-level space manager (chunks and blocks within chunks) plus being based on (nearly) copy-on-write, benefits from more space to be kept free, around 10-15%, and in particular from having at least one or a few chunks fully unallocated.
Podle chovani to spis vypada, ze se musi spis pouzivat onen ten rebalance, aby volne misto po smazanych souborech bylo pouzitelne. Taky historicky relikt z dob COW databazi.. a ja si myslel ze je uz rok 2025.. a ne 1970 :)
-
To je peklo s tím COW, že to potřebuje takovy "vacuum" jak pg ... a nikdo se o tom pořádně nezmiňuje ať si ten rebalance přidáš do cronu !
Ale asi pořád lepší to mít pod kontrolou, než aby uklízečka jela v kthreadu a řádila kdy to člověk nečeká a např. manipuluje s disky.
Na druhou stranu.. v případě, že alokace došla na konec, tak by měl proběhnout automatický rebalance pro získání alepoň jednoho volného chunku.. a to se neděje. Raději bych těch 10-20 sec IO latence přežil.. než -ENOSP, nebo nedejbože broken flag + RO.
Anketa.. kdo máte BTRFS a víte o nutnosti rebalance (defakto defragmentace a vacuuming) - a kdo ho v cronu i máte - nebo jste ještě nedošli na konec volného místa ?
Jo tohle při určitých workloadech a stylu používání může být problém. Taky jsem si během let při různých příležitostech vymáchal ústa (máme spolu s Btrfs z mnoha důvodů takový love-hate vztah :) ale samozřejmě to občas používám, primárně kvůli snapshotům a subvolume.
Trochu problém je, že pokud vím, tak nemáš úplně stoprocentní identifikátor (použitelný třeba v automatickém skriptu), že to jde do kopru a už si to neumí zaalokovat další gigový chunk. Např. i když bude reportovaná nějaké místo v "Device unallocated", tak nemusí být nutně kontinuální.
To prapodivné reportování volného místa, co se ti dělo, bych nejspíš tipoval na to, že neměl místo na metadata a zároveň tam chtěl uložit free space tree (byť tam je ještě ten rozdíl, že starý V1 nepoužíval CoW, zatímco novější V2 je normální strom a CoW používá). Byť by si měl asi v nějakých nejtěžších chvílích pomoct tím místem v Global Reserve, ale neznám přesně do detailu podmínky, kdy se to použije.
Jinak obecně žádné magické řešení úplně nemám, na normálních počítačích používám typicky btrfsmaintenance https://github.com/kdave/btrfsmaintenance, což je normálně ve SUSE i Fedoře. Ten periodicky spouští i lehčí rebalance. K tomu se to nesnažím plnit až po okraj.
Na některých místech, kde je to jako větší úložiště MD+BTRFS třeba na Synology a hrnou tam data ostatní lidé, tak je tam na data subvolume, kde je natvrdo kvóta pro uživatelská data, aby tam byl vždycky nějaký headroom.
Byť i ty kvóty můžou být občas problematické (zvlášť když je tam víc snapshotů).
Jinak vloni v Btrfs přibyla možnost zapnout mechanismus, který dynamicky spouští reclaim bloků.. což je ta tvoje uklízečka :)
https://lore.kernel.org/linux-btrfs/cover.1712168477.git.boris@bur.io/
Je to volba pro každý fs zvlášť, povoluje se v sysfs přes: /sys/fs/btrfs/<UUID>/allocation/data/dynamic_reclaim
Omezeně jsem to zkoušel na nějakých odílech a zásadně mě to nevypeklo ani nevadilo při provozu, ale nedělal jsem nějaké exaktní testy, kdy bych se to snažil dostat úplně na kolena.
-
Jinak vloni v Btrfs přibyla možnost zapnout mechanismus, který dynamicky spouští reclaim bloků.. což je ta tvoje uklízečka :)
https://lore.kernel.org/linux-btrfs/cover.1712168477.git.boris@bur.io/
Supr tip, diky!
Tak to zapínám v mount skriptu a cron nebudu zatím řešit. Pro ostatní, že co to dělá:
At a very high level, the dynamic threshold's strategy is to set a fixed target of unallocated block groups (10 block groups) and linearly scale its aggression the further we are from that target. That way we do no automatic reclaim until we actually press against the unallocated target, allowing the allocator to gradually fill fragmented space with new extents, but do claw back space after workloads that use and free a bunch of space, perhaps with fragmentation.
https://gitlab.com/fedora/ostree/sig/-/issues/77
-
Koupil jsem si 14TB, chci si tam ulozit 14TB !
Tak použijte jiný souborový systém. Různé souborové systémy mají různé vlastnosti. btrfs se zaměřuje spíš na šíři služeb poskytovaných souborovým systémem (např. RAID, snapshoty), což je vykoupeno tím, že není tak bezúdržbový jako jiné souborové systémy a nemá rád zaplnění až po okraj.
Všichni by rádi ideální souborový systém, který bude mít jen samé výhody, ale takový souborový systém neexistuje.
-
Supr tip, diky!
Tak to zapínám v mount skriptu a cron nebudu zatím řešit.
Není zač. Uvidíš, jestli to pro tebe bude funkční v tomhle dynamickém režimu.
Dovedu si představit použití obou metod v různých situacích. Jak naplánované volání balance z userspace utility, pokud má někdo třeba v noci malé vytížení úložiště. Nebo režim, kdy to můžeš pustit z hlavy, stará se o to přímo "uklízečka" ve fs, ale zaplatíš za to zpomalením při normální alokaci a používání, pokud tam začnou docházet volné bloky.
Jestli to zabírá bys měl poznat z položek ./allocation/data/reclaim_* v tom sysfs, jsou tam čítače od připojení fs.
-
Kde jsou ty casy kdy bylo x% rezervovanych pro roota a clovek se do podobne situace jako uzivatel nedostal… za me jakykoliv FS ktery dovoli uzivateli zapsat 100% a neumi se z toho sam dostat si zaslouzi jit do kose a ne na produkci.
-
za me jakykoliv FS ktery dovoli uzivateli zapsat 100% a neumi se z toho sam dostat si zaslouzi jit do kose a ne na produkci.
Toto se líbí uživateli Hans Reiser :P
-
Kde jsou ty casy kdy bylo x% rezervovanych pro roota a clovek se do podobne situace jako uzivatel nedostal… za me jakykoliv FS ktery dovoli uzivateli zapsat 100% a neumi se z toho sam dostat si zaslouzi jit do kose a ne na produkci.
To rezervovane misto plati pro systemovy disky... a tam to vyznam ma, resp. melo. Dnes uz ani kriticke sluzby nebezi pod rootem, aby se ke stroji dalo dostat.
Na datovych to rusim rovnou pri mkfs, nebo pres tune2fs napr.. tam root nikdy nezapisuje a bylo by to zbytecne omezeni - ale chapu ze mozna by to drive selhalo na dosle misto, nez aby se to dostalo do faze kdy se vycerpaj chunky datama a na metadata nedojde.
Nicmene takova ochrana, co vas klepne preventivne pres prsty.. neni to prave. Co kdyz nastane to dochazejici misto prave kdy zavirate praci a davate save, a pak utikate na vikend ci dovolenou.. proste toto nechces - kdyz tam to misto defakto je.
-
BTW ZFS to samy, nad 80% jde vykon dolu.
Mam podezreni, ze i kdybych mel 1 PTB a zbyvalo by 200 TB, stejne to bude kvicet a zacne to zpomalovat.
Koupil jsem si 14TB, chci si tam ulozit 14TB !
-
Kde jsou ty casy kdy bylo x% rezervovanych pro roota a clovek se do podobne situace jako uzivatel nedostal… za me jakykoliv FS ktery dovoli uzivateli zapsat 100% a neumi se z toho sam dostat si zaslouzi jit do kose a ne na produkci.
To rezervovane misto plati pro systemovy disky... a tam to vyznam ma, resp. melo. Dnes uz ani kriticke sluzby nebezi pod rootem, aby se ke stroji dalo dostat.
Na datovych to rusim rovnou pri mkfs, nebo pres tune2fs napr.. tam root nikdy nezapisuje a bylo by to zbytecne omezeni - ale chapu ze mozna by to drive selhalo na dosle misto, nez aby se to dostalo do faze kdy se vycerpaj chunky datama a na metadata nedojde.
Nicmene takova ochrana, co vas klepne preventivne pres prsty.. neni to prave. Co kdyz nastane to dochazejici misto prave kdy zavirate praci a davate save, a pak utikate na vikend ci dovolenou.. proste toto nechces - kdyz tam to misto defakto je.
Takze je lepsi pockat s ukladanim rozpracovanych dokumentu az do chvile kdy ti uplne dojde misto a jeste se ti k tomu roz$ebe filesystem? Zajimave… ja radsi prijdu o par hodin prace nez o cely filesystem.
-
BTW ZFS to samy, nad 80% jde vykon dolu.
Mam podezreni, ze i kdybych mel 1 PTB a zbyvalo by 200 TB, stejne to bude kvicet a zacne to zpomalovat.
Koupil jsem si 14TB, chci si tam ulozit 14TB !
Ja tohle zkousel a u takhle velkych poli je to lepsi nez 80%.
-
Takze je lepsi pockat s ukladanim rozpracovanych dokumentu az do chvile kdy ti uplne dojde misto a jeste se ti k tomu roz$ebe filesystem? Zajimave… ja radsi prijdu o par hodin prace nez o cely filesystem.
Clovek tady resi ECC, aby neprisel ani o bit ... a pak jsou nekteri lidi jako uplne v pohode s FS, ktery se sam podela, BY DESIGN, jen protoze autori odmitaji resit terminalni fazi.. a cele to stoji na tom, aby si uzivatel vsiml, ze pri 80% zaplneni se to zacina kapanek zpomalovat... tohle fakt jako dobre reseni neberu.
FS neni overclocking, kdy vam fyzika brani prekroceni hranic. Je to algoritmus a pevna logika.. ktera (bez AI cicovin) je porad predikovatelna a resitelna lepe.. nez to nechat dojit na segfault, v kernel mode.
-
Takze je lepsi pockat s ukladanim rozpracovanych dokumentu az do chvile kdy ti uplne dojde misto a jeste se ti k tomu roz$ebe filesystem? Zajimave… ja radsi prijdu o par hodin prace nez o cely filesystem.
Clovek tady resi ECC, aby neprisel ani o bit ... a pak jsou nekteri lidi jako uplne v pohode s FS, ktery se sam podela, BY DESIGN, jen protoze autori odmitaji resit terminalni fazi.. a cele to stoji na tom, aby si uzivatel vsiml, ze pri 80% zaplneni se to zacina kapanek zpomalovat... tohle fakt jako dobre reseni neberu.
FS neni overclocking, kdy vam fyzika brani prekroceni hranic. Je to algoritmus a pevna logika.. ktera (bez AI cicovin) je porad predikovatelna a resitelna lepe.. nez to nechat dojit na segfault, v kernel mode.
U ZFS dochazi pouze ke zpomaleni. U jakkehokoliv CoW filesystemu stejne musite kolem tech 90% nejak resit. Daji se nastavit quoty (ktere jsou skutecne hard) nebo zvol volumy s definovanou velikosti kde dostanete jako uzivatel natvrdo pres tlamu. Jako co ocekavate od COW filesystemu? Muzete si hrat s recordsize,logbias nebo resit kompresi na potlaceni efektu. To je ale asi tak vsechno protoze CoW tady nejde vypnout.
Je to jako kdyz nekdo chce jezdit F1 s tirakem. Kazda vec ma sve pouziti a sve specificke zpusoby ovladani. Pokud nemuzu zajistit nejaky buffer na FS na operace tak holt jak uz je tu zmineno asi mam spatny FS a pouziji jiny.
ZFS je FS primarne pro storage ktery si mate dale efektivne nasekat a spravovat tak aby se nedosahlo limitu. Na storagich se obvykle dostavate do uzkych pokud mate zaplnenost nad nejakou definovanou hodnotu prestanou fungovat urcite vyrobcem standartne podporovane akce.
U Btrfs to tez nebude jine, i kdyz lze narozdil od ZFS CoW kompletne vypnout pres nodatacow.
BTW: Prispevky tohoto typu tu ma clovek tak alespon 2x rocne. Proc mi jde ZFS na raspberry pi tak pomalu. Neco ve smyslu: Kdyz jsem si tam pridal nad to mdraid a mam pod tim i lvm2 tak je to horsi. Reseni neni drbat nevhodnou technologii az do krajnich mezi. Reseni je pouzit ji vhodnym zpusobem nebo vymenit.
-
Spis nez nodatacow v terminalni fazi bych zmenil a degradoval RAID level z 6 napr. na 5, pro data ktera nejsou vyslovene kriticka (a clovek ma beztak kopii v zaloze), coz je jednodussi, nez pridavat dalsi disk a provest rebalance (to by byla volba, pokud by HW mel volne pozice.. nema, takze nemuzu jednoduse provest ani upgrade na vetsi disky jako replace po jednom, zachodu).
Ale tohle u BTRFS nejde ta zmena udelat per-adresar nebo per-subvolume bohuzel. To ZFS to je myslim lepsi, ne?
-
Spis nez nodatacow v terminalni fazi bych zmenil a degradoval RAID level z 6 napr. na 5, pro data ktera nejsou vyslovene kriticka (a clovek ma beztak kopii v zaloze), coz je jednodussi, nez pridavat dalsi disk a provest rebalance (to by byla volba, pokud by HW mel volne pozice.. nema, takze nemuzu jednoduse provest ani upgrade na vetsi disky jako replace po jednom, zachodu).
Ale tohle u BTRFS nejde ta zmena udelat per-adresar nebo per-subvolume bohuzel. To ZFS to je myslim lepsi, ne?
Ne ZFS je na tom stejne ne-li hur. Treba u raidz je treba proste pri nove strukture vyrobit novy pool. U OpenZFS tusim 2.2 uz je k dispozici experimentalni funkce na rozsireni poolu.
Odebrani z poolu -> "RAIDZ Remove" nejde, neni ani v experimentalni fazi a v nejblizsi dobe se teprv zazne s implementaci. A jelikoz se tu nejedna o startup frikuliny tak implementace mozna zacne az v nasledujicich letech.
Remove/add lze v pohode jen u mirroru a add u stripe
Nebo se placnete pres kapsu a koupite si treba SitApp :-) Pripadne zcela zmenite vrstu nad ZFS a pouzijete ho jen jako node backend pro distribuovany fs.
-
Pardon, máš 84TB pole a potřebuje to zaplnit do posledního 1GB? Trochu divné použití, standard je nechal alespoň 20% volného, navíc volné místo se vždy hodí.
-
Pardon, máš 84TB pole a potřebuje to zaplnit do posledního 1GB? Trochu divné použití, standard je nechal alespoň 20% volného, navíc volné místo se vždy hodí.
84TB pole hlasilo 129 GB volneho mista.. chtel jsem ulozit jedno PDF... urcite nemelo 129GB ale spis 129KB. A o to me slo - ze nejen ze hlasene informace o volnem miste byla zcela neodpovidajici, ale dopadlo to kernel panicem (nastesti resitelnym, skrze par obskurnich prikazu a restartovanim NFS).
Po rebalance a manualnim "garbage collectingu" se to umoudrilo.
Z jakeho duvodu by mel clovek neverit volnemu mistu v DF prikazu? To popira zaklady logiky.. vidim volno, chci ho vyuzit.
Apropo - uz jsem Tomasi poslal ty disky co lidi od vas nakoupili?
-
Tedy měl jsem za to, že nepoužitelnost údajů z df je tak nějak obecně známá u souborových systémů typu zfs a btrfs...
-
Pardon, máš 84TB pole a potřebuje to zaplnit do posledního 1GB? Trochu divné použití, standard je nechal alespoň 20% volného, navíc volné místo se vždy hodí.
84TB pole hlasilo 129 GB volneho mista.. chtel jsem ulozit jedno PDF... urcite nemelo 129GB ale spis 129KB. A o to me slo - ze nejen ze hlasene informace o volnem miste byla zcela neodpovidajici, ale dopadlo to kernel panicem (nastesti resitelnym, skrze par obskurnich prikazu a restartovanim NFS).
Po rebalance a manualnim "garbage collectingu" se to umoudrilo.
Z jakeho duvodu by mel clovek neverit volnemu mistu v DF prikazu? To popira zaklady logiky.. vidim volno, chci ho vyuzit.
Apropo - uz jsem Tomasi poslal ty disky co lidi od vas nakoupili?
To nepopira zaklady logiky. To popira zaklady znalosti o COW systemech s kompresi,deduplikaci a snapshoty. Popira to take porozumeni dokumentaci.
Na zjisteni volneho mista na btrfs pouzivejte btrfs nastroje - btrfs filesystem df
Na zjisteni volneho mista pouzivejte zfs nastroje - zfs get used,avail,refer.
A poctete si zde:
https://docs.oracle.com/cd/E19253-01/819-5461/gbchp/index.html
Pouzivat df na btrfs/zfs je jako pouzivat v linuxu ifconfig a stezovat si ze pulku sitovych veci na tom nemuzu nastavit. Kazda vec ma svoje nastroje. Ano mohu v pripade nouze docasne pouzivat nastroj omezeny a nepresny, musim si ale byt vedom jeho limitaci. Dnes take nediagnostikujete auta nastroji z roku 1920.
Kazdy nastroj ma nejaka sva omezeni a nejaky okruh uziti kdy je vhodny a kdy mene vhodny.
Zkuste se vice zamerit na cil a ne na nastroj v tomto pripade.
-
COW nema nijaky magicky vliv na "free space" uz z principu (cow ma vliv leda na usage / celkovou velikost, pokud se pouzva sdileni bloku a deduplikace ci komprese).
Chybejici garbage collecting a defragmentace (dohromady a la vacuum) byl ten zdejsi problem + neschopnost FS driveru spravne obslouzit sve dve domeny (meta vs data), kdy jedna branila druhe ve vyuziti.
Link neni relevantni, nemam ZFS, nemam vice filesystems v poolu, nemam snapshotem zamcene data o kterych nevim.
// btw s ifconfig-em si vystacim taky - a to i v roce 2025 .. nevim jako proc pouzivat nejaky nesmyslny nabobtnaly tool a la systemd, pro jednoduche veci jako nastaveni IP (a imho "ip" je porad malo, kdyz clovek do sitariny musi nadale vrtat pres resolvconf a dalsi veci).
-
COW nema nijaky magicky vliv na "free space" uz z principu (cow ma vliv leda na usage / celkovou velikost, pokud se pouzva sdileni bloku a deduplikace ci komprese).
Chybejici garbage collecting a defragmentace (dohromady a la vacuum) byl ten zdejsi problem + neschopnost FS driveru spravne obslouzit sve dve domeny (meta vs data), kdy jedna branila druhe ve vyuziti.
Link neni relevantni, nemam ZFS, nemam vice filesystems v poolu, nemam snapshotem zamcene data o kterych nevim.
// btw s ifconfig-em si vystacim taky - a to i v roce 2025 .. nevim jako proc pouzivat nejaky nesmyslny nabobtnaly tool a la systemd, pro jednoduche veci jako nastaveni IP (a imho "ip" je porad malo, kdyz clovek do sitariny musi nadale vrtat pres resolvconf a dalsi veci).
Souvisi protoze to prinasi dalsi vrstvu komplexity. To o free space je velmi odvazne tvrzeni ktere bych veril mozna vyvojari fs u jednoducheho fs kde je CoW jako jednoducha deterministicka pridana feature i po 15ti pivech. Napr. u XFS. U BTRFS a ZFS (no dobre tam umim trochu debugovat) vubec netusim rychle a do 5 minut co se deje s metadaty, kde moje data jsou, co se deje kdyz je soubor ve stavu open a jak se chovaji "in transit" mezi jednotlivymi operacemi.
A nedozvedel jsem se to ani na "advanced / expert" skoleni ke storagim. Musite byt hardcore vyvojar.
A tim spis pokud si nejaky kabrnak pouzije experimentalni feature.
BTW: Jsou operacni systemy kde vetsinou s ifconfigem a par konfiguraky navrch vystacite. Ale linux to uz davno neni. Bez ethtoolu a ruznych servisnich utilitek na sitovky se neda fungovat. Routovacich tabulek a policy uz se nam taky namnozilo...
-
s ifconfigem a par konfiguraky navrch vystacite. Ale linux to uz davno neni. Bez ethtoolu a ruznych servisnich utilitek na sitovky se neda fungovat. Routovacich tabulek a policy uz se nam taky namnozilo...
No ano a proč to neudělat ještě lepší? Proč těch toolů nepřidat ještě 25...to je můl vlhký sen, abych na provedení jednoduchých úkolů potřeboval dva doktoráty. Tady je vidět, jak Linux uvnitř pomalu hnije.
A pokud df není schopno vrátit správnou hodnotu volného místa, tak má vrátit chybový kód.
-
No ano a proč to neudělat ještě lepší? Proč těch toolů nepřidat ještě 25...to je můl vlhký sen, abych na provedení jednoduchých úkolů potřeboval dva doktoráty. Tady je vidět, jak Linux uvnitř pomalu hnije.
Ty v Linuxu dávno zastaralé utility jsou dvě: ifconfig a route. Nová je jedna: ip. Takže i podle toho vašeho měřítka „počet utilit“ je balík iproute2 lepší.
(Pak má také tu výhodu, že na rozdíl od ifconfig/route vždy funguje, ale zdá se, že tohle kritérium pro mnohé není podstatné.)
-
A pokud df není schopno vrátit správnou hodnotu volného místa, tak má vrátit chybový kód.
Ano, napr. tak, jak to dela u inode usage (df -i ... vraci 0 / 0 / 0 pro btrfs)
Alternativne by to mohlo vratit toleranci jako GPS ... free: 128GB ±32GB :D
@Trident Vasco - vlastne vim proc nepouzivam by default btrfs filesystem df ... protoze:
- ten komp kde je BTRFS je jako NAS, a sdili to storage pres NFS. Takze na klientovi by onen prikaz nefungoval a je tam jen df
- pokazde namisto df pouzivat "ssh host btrfs filesystem df /mnt/neco" ... a hledat v tom je trocha meh. Ne nadarmo je "df" tak zkraceny.. protoze to potrebujes porad.
- a pak - az by bylo vice ulozist, tak to poustet rucne pro vsechny pro rychly prehled stavu?
- apropo "btrfs filesystem df" nezobrazi volne misto.. musis si ho spocitat (Data, RAID6: total=75.88TiB, used=75.73TiB), snad tam jde alespon vypnout
A cely to je dost blbe zas, o 2 nasobek:
$ df -h /mnt/neco/
Filesystem Size Used Avail Use% Mounted on
host:/neco 102T 77T 367G 100% /mnt/necovs
btrfs fi df /mnt/neco
Data, RAID6: total=75.88TiB, used=75.73TiB
echo $(( ( 75880 - 75730 ) * 1024 / 1000 ))
153vs
$ btrfs fi usage /mnt/neco
Free (estimated): 366.87GiB (min: 252.50GiB)
Free (statfs, df): 366.84GiB
Takze je volne misto ono FREE z btrfs filesystem usage, nebo ten rozdil z btrfs filesystem df ?
Pokud to mensi z df.. tak proc je FREE o stovku GB vetsi a kam se to misto podelo??
Vysledek je totiz, ze btrfs filesystem df je spatne - jsou tam stovky GB nealokovane, takze tebou doporuceny btrfs filesystem df nerika kolik toho muzu ulozit, ale kolik toho bylo smazano v ramci soucasnych alokaci. Dalsi volne misto je tady:
Unallocated:
/dev/mapper/sed_sde1 34.29GiB
/dev/mapper/sed_sdk1 34.32GiB
/dev/mapper/sed_sdq1 34.32GiB
/dev/mapper/sed_sdn1 34.32GiB
/dev/mapper/sed_sdb1 34.32GiB
/dev/mapper/sed_sdh1 34.32GiB
/dev/mapper/sed_sdt1 34.29GiB
/dev/mapper/sed_sdw1 34.29GiB
A tohle unallocated misto zobrazuje df rozhodne verohodneji ( 34.3 * (8-2) = 205.8 unallocated + 153 freed = 358.8 )
-
Podle mých zkušeností df nad btrfs sice dřív ukazoval špatné výsledky, ale to už je dávno odstraněno. Používám df úplně běžně. Ale zato btrfs filesystem df nepoužívám. btrfs filesystem usage mi přijde mnohem přívětivější. A ty údaje se od běžného df skoro neliší.
-
Takze je lepsi pockat s ukladanim rozpracovanych dokumentu az do chvile kdy ti uplne dojde misto a jeste se ti k tomu roz$ebe filesystem? Zajimave… ja radsi prijdu o par hodin prace nez o cely filesystem.
Clovek tady resi ECC, aby neprisel ani o bit ... a pak jsou nekteri lidi jako uplne v pohode s FS, ktery se sam podela, BY DESIGN, jen protoze autori odmitaji resit terminalni fazi.. a cele to stoji na tom, aby si uzivatel vsiml, ze pri 80% zaplneni se to zacina kapanek zpomalovat... tohle fakt jako dobre reseni neberu.
FS neni overclocking, kdy vam fyzika brani prekroceni hranic. Je to algoritmus a pevna logika.. ktera (bez AI cicovin) je porad predikovatelna a resitelna lepe.. nez to nechat dojit na segfault, v kernel mode.
Predikovatelna... hmm a proto jsme u Sunu meli velkou testovaci farmu kde bezely ruzne scenare tydny i mesice. Stejne se neprotestovalo vsechno a prvni verze zhucely na primitivnich use cases typu "hu-man u konzole" si spletl disky a nebral v potaz ruznou velikost bloku disku. A kazda blba feature se musela protestovat mnoha scenari. Milionkrat jsem ten filesystem rozmlatil abych mu veril i v krajnich pripadech.
Takze predikovatelne to mozna teoreticky je, prakticky je tam tolik ruznych kombinacia edge cases ze to neni mozne postihnout vsechno. Pokud se nasla nejaka bota tak se slo zpetne po testech a zjistovalo se proc to nezachytily. Dost casto za to mohl prilis synteticky charakter testu.
Prijde mi tedy ze dost podcenujete komplexitu ktera u BTRFS musi byt srovnatelna.
A jak se testuje profesionalne BTRFS? SuSE/Meta? A nevymezi testovani jen na pro ne momentalni kriticke features a v produkci bezi zmrazena stabilni verze?
Z tohoto duvodu bych pro NASku aspon nepouzival experimentalni features a mel po ruce implementaci ktera se nekde pouziva a nebo podporuje pro koncaky.