Nekorektní chování BTRFS

[RDa]

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:

Kód: [Vybrat]

[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:

Kód: [Vybrat]

[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:

Kód: [Vybrat]

[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


Kód: [Vybrat]

[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:

Kód: [Vybrat]

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/****

Kód: [Vybrat]

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/****

Kód: [Vybrat]

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/****

Kód: [Vybrat]

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

Kód: [Vybrat]

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

Kód: [Vybrat]

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:

Kód: [Vybrat]

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

[Reklama]

[Radek Zajíc]

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.

[RDa]

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.

[rmrf]

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.

[a12]

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.

[Reklama]

[RDa]

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 :)

[Michal Šmucr]

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.

[RDa]

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

[Filip Jirsák]

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.

[Michal Šmucr]

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.

[Petr Branik]

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.

[LolPhirae]

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 

[RDa]

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.

[pruzkumbojem]

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 !

[Petr Branik]

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.