Re: BTRFS setup advice for laptop performance ?

[Hugo Mills <hugo@carfax.org.uk>]

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

On Fri, Apr 04, 2014 at 10:02:27AM +0200, Swâmi Petaramesh wrote:
> Hi,
> 
> I'm going to receive a new small laptop with a 500 GB 5400 RPM mechanical 
> "ole' rust"  HD, and I plan ton install BTRFS on it.
> 
> It will have a kernel 3.13 for now, until 3.14 gets released.
> 
> However I'm still concerned with chronic BTRFS dreadful performance and still 
> find that BRTFS degrades much over time even with periodic defrag and "best 
> practices" etc.

   There's something funny going on here. There are, apparently, a
reasonable number of people using btrfs in daily use, with things like
snapper (regular and frequent snapshots). I'm one of them, although I
don't use snapper. We don't have lots of reports of massive slowdowns
after a long period of use, so whatever you're doing, there seems to
be something unusual involved.

   It's almost certainly not your fault, but there would appear to be
something in your configuration or your use-case which is leading to
these problems, and without knowing what's different, it's hard to set
about identifying the problem.

   What software do you run on the machine? Browser? Any databases?
Anything that contains a database? Torrents or other filesharing
software? Bitcoin mining? Bitcoin wallet? Anything else beyond the
ordinary boring desktop/office type applications? Are you compiling
lots of things (e.g. Gentoo)? Creating and deleting lots of files? If
so, large ones or small ones? Are you running very close to a full
filesystem? How are you measuring the slowdown -- do you have a
specific piece of benchmarking software, or just anecdotal evidence?

> So I'd like to start with the best possible options and have a few questions :
> 
> - Is it still recommended to mkfs with a nodesize or leafsize different 
> (bigger) than the default ? I wouldn't like to lose too much disk space anyway 
> (1/2 nodesize per file on average ?), as it will be limited...

   No, nodes are used for the metadata trees, not for file storage.
I'd suggest nodesize=leafsize=16k or 32k. I don't think you can change
the block size at the moment.

> - Is it recommended to alter the FS to have "skinny extents" ? I've
> done this on all of my BTRFS machines without problem, still the
> kernel spits a notice at mount time, and I'm worrying kind of "Why
> is the kernel warning me I have skinny extents ? Is it bad ? Is it
> something I should avoid ?"

   As far as I know, they're considered safe and stable. I suspect
that the message is just a developer info thing that hasn't been taken
out yet.

> - Are there other optimization tricks I should perform at mkfs time because 
> thay can't be changed later on ?

   Nodesize/leafsize are the only things you should probably change at
mkfs time. The other thing would be --mixed, but you probably don't
want that on a 500 GiB drive.

> - Are there other btrfstune or mount options I should pass before
> starting to populate the FS with a system and data ?

   I think everything else other than the above can be done after the
fact with btrfstune. I'd definitely suggest extended inode refs simply
because it fixes a known limitation.

> - Generally speaking, does LZO compression improve or degrade performance ? 
> I'm not able to figure it out clearly.

   Yes, it improves or degrades performance. :)

   It'll depend entirely on what you're doing with it. If you're
storing lots of zeroes (Phoronix, I'm looking at you), then you'll get
huge speedups. If you're storing video data, you'll get a (very)
slight performance drop as it scompresses the first few blocks of the
file and then gives up. I suspect that in general, the performance
differences won't be noticable unless you have highly compressible
large files, but if you _really_ care about it, benchmark it(*).

   Hugo.

(*) If you don't want to go through the effort of benchmarking, you
don't care enough about it, and should just pick something at random.

-- 
=== Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk ===
  PGP key: 65E74AC0 from wwwkeys.eu.pgp.net or http://www.carfax.org.uk
  --- And what rough beast,  its hour come round at last / slouches ---  
                     towards Bethlehem,  to be born?                     

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 811 bytes --]