Re: Massive BTRFS performance degradation

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

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

On Sun, Mar 09, 2014 at 11:23:29AM +0100, Swâmi Petaramesh wrote:
> Le dimanche 9 mars 2014 11:01:17 vous avez écrit :
> > This ThinkPad T520 has been with BTRFS since installation of the Debian
> > sid system on it with Kernel 2.6.39 or even 2.6.38 (where Sandybridge
> > graphics didn´t work so well as today yet).
> >
> > So that much to any FUD about BTRFS and SSDs.
> 
> Wow !
> 
> Thanks for this very interesting info. Would you tell me if you use any of the 
> SSD optimisation mount options: discard, ssd or ssd_spread ?

   I would recommend none of the three. :)

   ssd should be activated automatically on any non-rotational device.
ssd_spread is generally slower on modern SSDs than the ssd option.
discard is, except on the very latest hardware, a synchronous command
(it's a limitation of the SATA standard), and therefore results in
very very poor performance.

[snip]
> I've been used to consider for 3 years that :
> 
> - Next kernel release will have a truly excellent and mature BTRFS support.

   I don't think anyone's claimed that. The next version tends to fix
most of the *known* problems.

> - Current kernel release has correct BTRFS support - but most
> mainline distros don't have it yet, maybe in 6 months ?

   This is usually true -- but by the time the current kernels come
round, there's usually been another swathe of bugs uncovered, thus
falling into this problem:

> - Previous kernel release (the one that all current distros come
> with) have a completely broke BTRFS support...

   Not completely broken, but with known and identified bugs that have
been fixed in later versions.

> #LOL
> 
> Well I hope it's quite not the case anymore for I just installed my neighbour, 
> old lady's system with a Linux Mint 16 (kernel 3.11) on BTRFS with skinny 
> extents...

   There's one known and serious bug in 3.11 before 3.11.6 which
affects balances. Please make sure that you're running 3.11.6 or
later. There may be other bugs in there that have been fixed in later
kernel versions as well, but that's the "headline" one.

> But for myself running ArchLinux in kernel 3.13, I still find out that :
> 
> - "btrfs send" causes my kernel to BUG :-/ (the wiki says it's working 
> stuff...)

   We don't get many bug reports of kernel oopses in send. This may be
that we don't have many people trying to use it (it is, after all,
fairly deep and poorly explained magic at the moment). It may be that
you have some corruption that's gone undetected otherwise, and the
send code isn't handling it well. Or it may be an actual bug in send.
At least you've reported it. (It might also be worth putting a copy of
the report on bugzilla.kernel.org, because then it doesn't get
forgotten in the email noise here).

> - btrfs-defrag.sgh hangs because of some glitch with "filefrag".

   Is that a btrfs problem, or a filefrag problem? btrfs-defrag.sh
isn't something I've heard of before, so I'd say it's unlikely to be
maintained by any of the main btrfs developers (and hence is much more
likely to be unmaintained or just plain broken in general).

> - bedup crashes badly and looks completely unmaintained as far as I can tell 
> and nobody seems to care.

   That's because nobody here is connected to bedup in any way. It was
a third-party piece of software written by someone (I don't even
recall who) who hasn't, as far as I know, engaged with the main btrfs
developers at all.

> Soooo weeelllll... Looks like readiness for prime time is still
> ahead of us...

   I think that's fair to say. However, it is noticeably improving
over time. The timescales are just quite long.

   Hugo.

-- 
=== 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
   --- Well, you don't get to be a kernel hacker simply by looking ---   
                    good in Speedos. -- Rusty Russell                    

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