Re: Is it necessary to balance a btrfs raid1 array?

[Austin S Hemmelgarn <ahferroin7@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3286 bytes --]

On 2014-09-10 09:48, Rich Freeman wrote:
> On Wed, Sep 10, 2014 at 9:06 AM, Austin S Hemmelgarn
> <ahferroin7@gmail.com> wrote:
>> Normally, you shouldn't need to run balance at all on most BTRFS
>> filesystems, unless your usage patterns vary widely over time (I'm
>> actually a good example of this, most of the files in my home directory
>> are relatively small, except for when I am building a system with
>> buildroot or compiling a kernel, and on occasion I have VM images that
>> I'm working with).
> 
> Tend to agree, but I do keep a close eye on free space.  If I get to
> the point where I'm over 90% allocated to chunks with lots of unused
> space otherwise I run a balance.  I tend to have the most problems
> with my root/OS filesystem running on a 64GB SSD, likely because it is
> so small.
> 
> Is there a big performance penalty running mixed chunks on an SSD?  I
> believe this would get rid of the risk of ENOSPC issues if everything
> gets allocated to chunks.  There are obviously no issues with random
> access on an SSD, but there could be other problems (cache
> utilization, etc).
There shouldn't be any more performance penalty than for normally
running mixed chunks.  Also, a 64GB SSD is not small, I use a pair of
64GB SSD's in a BTRFS RAID1 configuration for root on my desktop, and
consistently use less than a quarter (12G on average) of the available
space, and that's with stuff like LibreOffice and the entire OpenClipart
distribution (although I'm not running an 'enterprise' distribution, and
keep /tmp and /var/tmp on tmpfs).
> 
> I tend to watch btrfs fi sho and if the total space used starts
> getting high then I run a balance.  Usually I run with -dusage=30 or
> -dusage=50, but sometimes I get to the point where I just need to do a
> full balance.  Often it is helpful to run a series of balance commands
> starting at -dusage=10 and moving up in increments.  This at least
> prevents killing IO continuously for hours.  If we can get to a point
> where balancing can operate at low IO priority that would be helpful.
> 
> IO priority is a problem in btrfs in general.  Even tasks run at idle
> scheduling priority can really block up a disk.  I've seen a lot of
> hurry-and-wait behavior in btrfs.  It seems like the initial commit to
> the log/etc is willing to accept a very large volume of data, and then
> when all the trees get updated the system grinds to a crawl trying to
> deal with all the data that was committed.  The problem is that you
> have two queues, with the second queue being rate-limiting but the
> first queue being the one that applies priority control.  What we
> really need is for the log to have controls on how much it accepts so
> that the updating of the trees/etc never is rate-limiting.   That will
> limit the ability to have short IO write bursts, but it would prevent
> low-priority writes from blocking high-priority read/writes.

You know, you can pretty easily control bandwidth utilization just using
cgroups.  This is what I do, and I get much better results with cgroups
and the deadline IO scheduler than I ever did with CFQ. Abstract
priorities are a not bad for controlling relative CPU utilization, but
they really suck for IO scheduling.


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 2455 bytes --]