On 2014-09-10 09:48, Rich Freeman wrote: > On Wed, Sep 10, 2014 at 9:06 AM, Austin S Hemmelgarn > <ahferro...@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.
smime.p7s
Description: S/MIME Cryptographic Signature
