On 08/01/18 16:34, Austin S. Hemmelgarn wrote: > Ideally, I think it should be as generic as reasonably possible, > possibly something along the lines of: > > A: While not strictly necessary, running regular filtered balances (for > example `btrfs balance start -dusage=50 -dlimit=2 -musage=50 -mlimit=4`, > see `man btrfs-balance` for more info on what the options mean) can help > keep a volume healthy by mitigating the things that typically cause > ENOSPC errors. Full balances by contrast are long and expensive > operations, and should be done only as a last resort. That recommendation is similar to what I do and it works well for my use case. I would recommend it to anyone with my usage, but cannot say how well it would work for other uses. In my case, I run balances like that once a week: some weeks nothing happens, other weeks 5 or 10 blocks may get moved. For reference, my use case is for two separate btrfs filesystems each on a single large disk (so no RAID) -- the disks are 6TB and 12TB, both around 80% used -- one is my main personal data disk, the other is my main online backup disk. The data disk receives all email delivery (so lots of small files, coming and going), stores TV programs as PVR storage (many GB sized files, each one written once, which typically stick around for a while and eventually get deleted) and is where I do my software development (sources and build objects). No (significant) database usage. I am guessing this is pretty typical personal user usage (although it doesn't store any operating system files). The only unusual thing is that I have it set up as about 20 subvolumes, and each one has frequent snapshots (maybe 200 or so subvolumes in total at any time). The online backup disk receives backups from all my systems in three main forms: btrfs snapshots (send/receive), rsnapshot copies (rsync), and DAR archives. Most get updated daily. It contains several hundred snapshots (most received from the data disk). It would be interesting to hear if similar balancing is seen as useful for other very different cases (RAID use, databases or VM disks, etc). Graham -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
