[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 ]---
[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
[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
113T 84T 0 100% /mnt/****
↕
113T 84T 909G 100% /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
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%)
~
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
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
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
Metadata,RAID6: Size:134.62GiB, Used:133.98GiB (99.52%)
↓
Metadata,RAID6: Size:142.88GiB, Used:142.19GiB (99.52%)
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.
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
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.
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 ?
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/
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.
Supr tip, diky!
Tak to zapínám v mount skriptu a cron nebudu zatím řešit.
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.
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.
Koupil jsem si 14TB, chci si tam ulozit 14TB !Citace
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.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 !CitaceJa 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.
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.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.
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).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.
Ale tohle u BTRFS nejde ta zmena udelat per-adresar nebo per-subvolume bohuzel. To ZFS to je myslim lepsi, ne?
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í.
To nepopira zaklady logiky. To popira zaklady znalosti o COW systemech s kompresi,deduplikaci a snapshoty. Popira to take porozumeni dokumentaci.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?
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).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.
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).
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.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ší.
A pokud df není schopno vrátit správnou hodnotu volného místa, tak má vrátit chybový kód.
$ 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
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
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 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.
Overall:
Device size: 130.97TiB
Device allocated: 130.93TiB
Device unallocated: 40.11GiB
Device missing: 0.00B
Device slack: 0.00B
Used: 129.98TiB
Free (estimated): 738.63GiB (min: 721.92GiB)
Free (statfs, df): 738.59GiB
Data ratio: 1.33
Metadata ratio: 3.00
Global reserve: 512.00MiB (used: 0.00B)
Multiple profiles: no
Data,RAID6: Size:97.85TiB, Used:97.16TiB (99.29%)
/dev/***0 16.31TiB
/dev/***1 16.31TiB
/dev/***2 16.31TiB
/dev/***3 16.31TiB
/dev/***4 16.31TiB
/dev/***5 16.31TiB
/dev/***6 16.31TiB
/dev/***7 16.31TiB
žádný raid ti nepojede při obsazenosti 99.29% proboha
Těch 700 MB nejspíš nebude volné místo v jednom kuse, ale všemožné malé kousíčky rozeseté různě po diskuO čemž si lze tak trochu udělat představu příkazem:
žádný raid ti nepojede při obsazenosti 99.29% proboha
Těch 700 MB nejspíš nebude volné místo v jednom kuse, ale všemožné malé kousíčky rozeseté různě po diskuO čemž si lze tak trochu udělat představu příkazem:
btrfs inspect-internal list-chunks /path
# head inspect-list-chunks.txt -n 12
Devid PNumber Type/profile PStart Length PEnd LNumber LStart Usage%
----- ------- ------------------ ---------- ---------- ---------- ------- ---------- ------
1 1 Data/RAID6 1.00MiB 6.00GiB 6.00GiB 14771 119.46TiB 0.00
1 2 Data/RAID6 1.00GiB 6.00GiB 7.00GiB 1 37.03GiB 0.00
1 3 Data/RAID6 2.00GiB 6.00GiB 8.00GiB 2 43.03GiB 0.00
1 4 Data/RAID6 3.00GiB 6.00GiB 9.00GiB 3 49.03GiB 0.00
1 5 Data/RAID6 4.00GiB 6.00GiB 10.00GiB 4 55.03GiB 0.00
1 6 Data/RAID6 5.00GiB 6.00GiB 11.00GiB 5 61.03GiB 0.00
1 7 Data/RAID6 6.00GiB 6.00GiB 12.00GiB 6 67.03GiB 0.00
1 8 Data/RAID6 7.00GiB 6.00GiB 13.00GiB 7 73.03GiB 0.00
1 9 Data/RAID6 8.00GiB 6.00GiB 14.00GiB 8 79.03GiB 0.00
1 10 Data/RAID6 9.00GiB 6.00GiB 15.00GiB 9 85.03GiB 0.00
# grep inspect-list-chunks.txt -ve '0.00$'
Devid PNumber Type/profile PStart Length PEnd LNumber LStart Usage%
----- ------- ------------------ ---------- ---------- ---------- ------- ---------- ------
# wc -l inspect-list-chunks.txt
134104 inspect-list-chunks.txt
To je tedy opravdu zajímavé. S tím ti asi neporadím. Ale zajímalo by mne, jakou máš verzi kernelu a btrfs-progs. AI píše, že při takovém zaplnění nemusí btrfs stíhat obnovovat interní datové struktury. Ona ale dost kecá. Chápal bych možnost těch chyb, ale v takovém případě by se to nepochybně projevilo také hlášením v logu.
# btrfs version
btrfs-progs v6.17
-EXPERIMENTAL -INJECT -STATIC +LZO +ZSTD -UDEV +FSVERITY +ZONED CRYPTO=builtin
# uname -a
Linux ******.***.*******.*** 6.17.6-gentoo-x86_64 #1 SMP PREEMPT_DYNAMIC Sat Nov 1 12:43:31 CET 2025 x86_64 Intel(R) Xeon(R) Gold 6130 CPU @ 2.10GHz GenuineIntel GNU/Linux# btrfs versionHezké...
btrfs-progs v6.17
# uname -a
Linux ******.***.*******.*** 6.17.6-gentoo-x86_64 #1 SMP PREEMPT_DYNAMIC Sat Nov 1 12:43:31 CET 2025 x86_64 Intel(R) Xeon(R) Gold 6130 CPU @ 2.10GHz GenuineIntel GNU/Linux
Aktualizace tech statistik se da nejak vynutit ?No to asi těžko.
žádný raid ti nepojede při obsazenosti 99.29% proboha
A to ma jakoze jaky duvod? Je tam 700 GB volneho mista. Proc to misto tedy neni dostupno? (tentokrat to uz mistem v metadatech omezeny fakt neni).
í o hranici 80% obsazenosti. Ze zkušeností, co mám já, tak fungují do 90% ale dál už bych nešel.
í o hranici 80% obsazenosti. Ze zkušeností, co mám já, tak fungují do 90% ale dál už bych nešel.
Takže ze 100 TB mohu využít jen 80 TB? Nebo 90TB? A proč mi musí 10-20 TB ležet ladem?
Mám i 400TB pole, to mi má ležet ladem 80TB?