2016-09-20 10:48 GMT+02:00 Hugo Mills <h...@carfax.org.uk>: > On Tue, Sep 20, 2016 at 10:34:49AM +0200, Peter Becker wrote: >> More details on the issue and a complete explantion you can find here: >> >> http://marc.merlins.org/perso/btrfs/post_2014-05-04_Fixing-Btrfs-Filesystem-Full-Problems.html >> and >> (Help! I ran out of disk space! ) >> https://btrfs.wiki.kernel.org/index.php/FAQ#Help.21_I_ran_out_of_disk_space.21 >> >> And an explantion for the "dlimit" solution: > > It's not "dlimit". It's "d" with option "limit". You could just as > easily write -dusage=99,limit=10 or -dlimit=10,usage=99 (although > those aren't the options I'd pick... see below). > >> Quote From: Uncommon solutions for BTRFS >> (http://blog.schmorp.de/2015-10-08-smr-archive-drives-fast-now.html) >> >> > For my purposes, I define internal fragmentation as space allocated but >> > not usable by the filesystem. In BTRFS, each time you delete files, the >> > space used by those files cannot be reused for new files automatically. >> > It's not a hard requirement to do this maintenance regularly, but doing it >> > regularly spares you waiting for hours when the disk is full and you need >> > to wait for a balance clean up command - and of course also reduces the >> > number of > times you get unexpected disk full errors. As a side note, >> > this can also be useful to prolong the life of your SSD because it allows >> > the SSD to reuse space not needed by the filesystem (although there is a >> > trade-off, frequent balancing is bad, no balancing is bad, the sweet spot >> > is somewhere in between). >> >> 2016-09-20 10:20 GMT+02:00 Peter Becker <floyd....@gmail.com>: >> > Normaly total and used should deviate us a few gb. >> > depend on your write workload you should run >> > >> > btrfs balance start -dusage=60 /mnt >> > >> > every week to avoid "ENOSPC" >> > >> > if you use newer btrfs-progs who supper balance limit filters you should >> > run >> > >> > btrfs balance start -dusage=99 -dlimit=10 /mnt >> > >> > every 3 hours. > > These two options both feel horrible to me. Particularly the second > option, which is going to result in huge write load on the FS, and is > almost certainly going to be unnecessary most of the time.
I take this from kdave's btrfs maintence scripts and this works for me since one year. (https://github.com/kdave/btrfsmaintenance) > My recommendation would be to check at regular intervals (daily, > say) whether the used value is equal to the size value in btrfs fi > show. If it is (and only if), then you should run a balance with no > usage= option, and with limit=<n>, for some relatively small value of > <n> (3, say). That will give you some unallocated space that the FS > can take for metadata should it need it, which is all that's required > to avoid early ENOSPC. With no usage-option, how to avoid balance full blocks? -dusage=99 only balance blocks with empty space. > If you regularly find that your usage patterns result in large > numbers of empty or near-empty block groups (i.e. lots of headroom in > data shown by btrfs fi df), then a regular (but probably less > frequent) balance with something like usage=5 should keep that down. > >> > This will balance 2 Blocks (dlimit=10; corresponds to 10 gb) with are > > No, it will balance 10 complete block groups, not 10 GiB. Depending > on the RAID configuration, that could be a very large amount of data > indeed. (For example, an 8-disk RAID-10 would be rewriting up to 80 > GiB of data with that command). Thanks for this clarification. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
