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

Reply via email to