4 ms·
Not defending them in any way, but I know with my Infrant (then Netgear unfortunately, who last year killed the products) ReadyNASs which also used mdadm to con
by pixelesque 1y ago
Not defending them in any way, but I know with my Infrant (then Netgear unfortunately, who last year killed the products) ReadyNASs which also used mdadm to configure BTRFS with RAID5 in a similar way to Synology and QNAP, the recommendation was that you don't want your BTRFS filesystem to run low on space, because then it runs out of metadata space, and if it does that it becomes read-only, and can become unstable.
Basically, the recommendation was to always have 5% free space, so this isn't just Synology saying this.
- pixelesque 1y agoActually, reading the BTRFS docs, they recommend keeping 5-10% free space: https://archive.kernel.org/oldwiki/btrfs.wiki.kernel.org/index.php/SysadminGuide.html#Balancing https://archive.kernel.org/oldwiki/btrfs.wiki.kernel.org/ind...
- MrDrMcCoy 1y agoYup. After having dealt with that, I err on the side of caution and don't even let it merge small files into inodes for space savings. I still love btrfs for the CoW, snapshots, and compression, but you really gotta give that metadata a wide berth.
- magicalhippo 1y agoZFS has a similar limitation. It tries to mitigate this by reserving some space for metadata, to be used in emergencies, but apparently it's possible to exhaust it and get your filesystem into a read-only state. There was some talk about increasing the reservations to prevent this but can't recall if changes were made.
- izacus 1y agoThe recommendation of 5% free space comes from arrays in sizes of 100s of GB, not tens of TB. This is the same kind of issue that Linux root filesystems had - a % based limitation made sense when disks were small, but now they don't make a lot of sense anymore when they restrict usage of hundreds of GB (which are not actually needed by the filesystem to operate).