BTRFS setup advice for laptop performance ?

BTRFS setup advice for laptop performance ?

[Swâmi Petaramesh]

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.

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...

- 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 ?"

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

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

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

TIA for the insight.

-- 
Swâmi Petaramesh <swami@petaramesh.org> http://petaramesh.org PGP 9076E32E

Re: BTRFS setup advice for laptop performance ?

[Austin S Hemmelgarn]

On 2014-04-04 04:02, 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.
I keep hearing this from people, but i personally don't see this to be
the case at all.  I'm pretty sure the 'big' performance degradation that
people are seeing is due to how they are using snapshots, not a result
using BTRFS itself (I don't use them for anything other than ensuring a
stable system image for rsync and/or tar based backups).
> 
> 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...
This depends on many things, the average size of the files on the disk
is the biggest factor.  In general you should get the best disk
utilization by setting nodesize so that a majority of the files are less
than the leafsize minus 256 bytes, and all but a few are smaller than
two times the leafsize minus 256 bytes.  However, if you want to really
benefit from the data compression, you should just use the smallest
leaf/nodesize for your system (which is what mkfs defaults to), as data
that gets as BTRFS stores files whose size is at least (roughly) 256
bytes less than the leafsize inline with the metadata, and doesn't
compress such files.
> 
> - 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 ?"
I think that the primary reason for the warning is that it is backward
incompatible, older kernels can't mount filesystems using it.
> 
> - Are there other optimization tricks I should perform at mkfs time because 
> thay can't be changed later on ?
> 
> - Are there other btrfstune or mount options I should pass before starting to 
> populate the FS with a system and data ?
Unless you are using stuff like QEMU or Virtualbox, you should probably
have autodefrag and space_cache on from the very start.
> 
> - Generally speaking, does LZO compression improve or degrade performance ? 
> I'm not able to figure it out clearly.
As long as your memory bandwidth is significantly higher than disk
bandwidth (which is almost always the case, even with SSD's), this
should provide at least some improvement with respect to IO involving
large files.  Because you are using a traditional hard disk instead of
an SSD, you might get better performance using zlib (assuming you don't
mind slightly higer processor usage for IO to files larger than the
leafsize).  If you care less about disk utilization than you do about
performance, you might want to use compress_force instead of compress,
as the performance boost comes from not having to write as much data to
disk.
> 
> TIA for the insight.
> 

Re: BTRFS setup advice for laptop performance ?

[Swâmi Petaramesh]

Le vendredi 4 avril 2014 08:33:10 Austin S Hemmelgarn a écrit :
> > 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.
> 
> I keep hearing this from people, but i personally don't see this to be
> the case at all.  I'm pretty sure the 'big' performance degradation that
> people are seeing is due to how they are using snapshots, not a result
> using BTRFS itself (I don't use them for anything other than ensuring a
> stable system image for rsync and/or tar based backups).

Maybe I was wrong to suppose that if a feature exists, it is supposed to be 
usable... I have used ZFS for years, and on ZFS having *hundreds* of snapshots 
of any given FS have exactly zero impact on performance...

With BTRFS, some time ago I tried to use SuSE "snapper" that passes its time 
doing and releasing snapshots, but it soon made my systems unusable...

Now, I only keep 2-3 manually made snapshots just for keeping a "stable and OK 
archive of my machine in a known state" just in case...

But if even this has a noticeable negative impact on BTRFS performance, then 
what the hell are BTRFS snapshots good at ??

Kind regards.

-- 
Swâmi Petaramesh <swami@petaramesh.org> http://petaramesh.org PGP 9076E32E

Re: BTRFS setup advice for laptop performance ?

[Austin S Hemmelgarn]

On 2014-04-04 08:48, Swâmi Petaramesh wrote:
> Le vendredi 4 avril 2014 08:33:10 Austin S Hemmelgarn a écrit :
>>> 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.
>>
>> I keep hearing this from people, but i personally don't see this to be
>> the case at all.  I'm pretty sure the 'big' performance degradation that
>> people are seeing is due to how they are using snapshots, not a result
>> using BTRFS itself (I don't use them for anything other than ensuring a
>> stable system image for rsync and/or tar based backups).
> 
> Maybe I was wrong to suppose that if a feature exists, it is supposed to be 
> usable... I have used ZFS for years, and on ZFS having *hundreds* of snapshots 
> of any given FS have exactly zero impact on performance...
> 
> With BTRFS, some time ago I tried to use SuSE "snapper" that passes its time 
> doing and releasing snapshots, but it soon made my systems unusable...
> 
> Now, I only keep 2-3 manually made snapshots just for keeping a "stable and OK 
> archive of my machine in a known state" just in case...
> 
> But if even this has a noticeable negative impact on BTRFS performance, then 
> what the hell are BTRFS snapshots good at ??
> 
> Kind regards.
> 
I'm not saying that using a few snapshots is a bad thing, I'm saying
that thousands of snapshots is a bad thing (I have actually seen people
with hat many, including one individual who had almost 32,000 snapshots
on the same drive).  I personally do keep a few around on my system on a
regular basis, even aside from the backups, and have no noticable
performance degradation.  For reference, the (main) system that I am
using has a Intel Celeron 847 running at 1.1GHz, 4G of DDR3-1333 RAM,
and a 500G 5400 RPM SATAII hard disk.  My root filesystem is BTRFS
volume mounted with autodefrag,space_cache,compress-force=lzo,noatime
(the noatime improves performance (and power efficency) for btrfs
because metadata updates end up cascading up the metadata tree (updating
the atime on /etc/foo/bar causes the atime to be updated on /etc/foo,
which causes the atime to be updated on /etc, which causes the atime to
be updated on /)

Re: BTRFS setup advice for laptop performance ?

[Duncan]

Austin S Hemmelgarn posted on Fri, 04 Apr 2014 08:33:10 -0400 as
excerpted:

> On 2014-04-04 04:02, 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.

Reminds me of my query to the list, some months ago.  (Altho I was/am 
using dual 238 GiB SSDs, in btrfs raid1 mode both data and metadata, in a 
desktop, additionally with a 500 gig spinning rust drive for media that 
is still running reiserfs, so the details are somewhat different.)

>> It will have a kernel 3.13 for now, until 3.14 gets released.

$ uname -r
3.14.0

=:^)

But it's good you (SP) keep reasonably current.  I see people posting 
with old 2.6.* kernels and wonder why they're even bothering with btrfs, 
since they obviously aren't current, kernel-wise.

>> 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.

> I keep hearing this from people, but i personally don't see this to be
> the case at all.  I'm pretty sure the 'big' performance degradation that
> people are seeing is due to how they are using snapshots, not a result
> using BTRFS itself (I don't use them for anything other than ensuring a
> stable system image for rsync and/or tar based backups).

I'll second what you (AH) and Hugo say elsewhere, and I've written some 
on the subject in other threads too.  Snapshots per se aren't bad, but 
there's really no reason to have thousands of them against the same base 
subvolume -- in practice, if you need to mount a snapshot a month or six 
old, are you really going to know or care what exact minute to mount?

While I /personally/ think per-minute snapshots are overdoing it, per 
hour or so is definitely logically supportable and if you /want/ per-
minute, well, fine.  But per-minute or per-hour or per-day, or just 
taking an occasional manual snapshot, /do/ strongly consider thinning 
them out on a reasonable schedule, and the more frequently you take 'em 
the more you need to thin.  So if for example you're taking per-minute, 
thin them down to perhaps one per half-hour after six hours and one per 
hour after a day, then to one a day after a week and one a week after 
four weeks.  At some point between a month and a quarter, external 
backups should have taken over, and deleting older snapshots or only 
keeping perhaps one every 13 weeks (quarter) should suffice.

Meanwhile, as Hugo hints there are still known issues with snapshots and 
large (half-gig-plus) frequently internally rewritten files such as VM 
images, databases, etc, even if set NOCOW.  If you're running something 
like this, strongly consider putting those files on a dedicated subvolume 
and using conventional backups instead of snapshotting for that 
subvolume.  (And set NOCOW using the directory inheritance mechanism 
described in other posts.)

For smaller stuff the autodefrag option should help.


>> 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...

> This depends on many things, the average size of the files on the disk
> is the biggest factor.  In general you should get the best disk
> utilization [snip]

As Hugo says, btrfs' current nodesize settings, etc, apply to metadata, 
not data, which is currently the standard 4K page-size on x86.  Metadata 
nodesize now defaults to 16K with newer mkfs.btrfs, which should be 
reasonable.  (There's work to make the data-block size configurable as 
well, in part because it's currently not possible to mount btrfs created 
on architectures with different page sizes, tho luckily both arm and x86/
amd64 have 4k page sizes so are compatible.)

>> - 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 ?"

> I think that the primary reason for the warning is that it is backward
> incompatible, older kernels can't mount filesystems using it.

Agreed.  When skinny extents first came out there were some initial bugs, 
but I believe they've been worked out by now in general, so it shouldn't 
be a problem.  The big remaining issue is backward compatibility.

Tho at least here (where I've been running 3.14 pre-releases since before 
rc1), the on-mount skinny-extents comment seems more informational than 
actual warning.

That said, more conservative users might wish to stay with "fat" extents, 
since AFAIK that's still the default, so it's going to get the most 
testing.  FWIW, when I last re-did my partitions in ordered to take 
advantage of the 16k metadata node-sizes, etc (late kernel 3.13 cycle I 
think), I kept fat extents on root and home, but went with skinny extents 
on my packages partition.  I've seen no issues with it in my usage, and 
will probably go all skinny-extent the next time I redo my partitions.

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

I used -O extref on all my partitions here, when I redid them.  That's 
probably a good idea.

The -m (mixed data/metadata) thing is interesting.  You probably don't 
want to do it on a 500 gig unless you partition up (tho some do for the 
dup mode benefit mentioned below), and it's the default on really small 
(gig and smaller) partitions, but some people use it on filesystems up to 
128 gig or so for a couple reasons.

Mixed mode does help avoid the issue of having to run a balance if data 
(typical) or metadata chunk allocations end up using all available space, 
since to the present, btrfs can automatically allocate new chunks of one 
or the other if there's unallocated chunks available, but can't 
reallocate empty chunks from one to the other if necessary, without a 
rebalance.  Mixed mode eliminates having to do a manual rebalance to 
return chunks to the unallocated pool so they can be used for the other 
type, since all chunks can then be used for data and metadata, both.  But 
it DOES have a bit of a performance impact.

The other and arguably more interesting feature of mixed mode for single 
device filesystems is that it allows and in fact defaults to dup profile 
mode for the now mixed data/metadata chunks, inheriting that default (as 
well as the 256 MiB chunk size) from the metadata side.  Since unlike 
metadata, data chunks are otherwise limited to single profile mode, mixed-
mode is the only way (other than creating two partitions on the same 
hardware device and running btrfs raid1 on that, but that's less 
efficient, particularly on spinning rust) to fully apply btrfs data 
integrity benefits to data chunks on a single device.  Normally, in case 
of corruption btrfs scrub on a single device filesystem can only recover 
metadata, since those are the only chunks in dup mode.  But with mixed-
mode, data and metadata share the same chunks and thus can both be dup, 
thus allowing data to be recovered from the other copy if one copy goes 
bad, as well as metadata.

To someone like me where a big reason for using btrfs at all is the data 
integrity aspect, thus my running two SSDs configured in btrfs raid1 mode 
for most partitions, if I were limited to a single hardware device (as I 
will be for my netbook, tho I've not actually converted it to btrfs yet), 
I may well consider mixed-mode, for the benefit of dup-mode data as well 
as metadata, alone!

Tho of course that does effectively limit you to half capacity, since all 
data and metadata is duplicated.  And on spinning rust it's going to be a 
performance issue, tho it should be less of one doing it that way than it 
would be forcing it with two identical partitions on the same hardware 
disk and setting btrfs up in raid1 mode.

But if you /do/ use mixed-mode, as I implied above, you may wish to break 
up that 500 gig into multiple 128 gig or so partitions, each with its own 
btrfs, as I believe your performance cost will be lower that way, than 
they'd be with a single 500 gig mixed-mode single-device btrfs.  But do 
remember when you'r setting up the partitions that dup mode does mean 
they get full with half the stuff they'd normally hold, and size the 
partitions accordingly!

>> - Are there other btrfstune or mount options I should pass before
>> starting to populate the FS with a system and data ?
> Unless you are using stuff like QEMU or Virtualbox, you should probably
> have autodefrag and space_cache on from the very start.

Agreed in general.  However, my experience is that space_cache is now the 
default, so you don't have to set that explicitly.

As for autodefrag, definitely strongly recommended, /except/ as mentioned 
for large (half-gig or larger) frequent-internal-rewrite files such as VM 
images and databases.  For large internal-write files I'd recommend 
putting them on their own dedicated subvolume (or fully separate 
partition) to avoid snapshotting, and setting up NOCOW for the affected 
directories.  (At some point individual subvolumes will be mountable with 
different options and the entire dedicated subvolume could then be 
mounted with nodatacow.  But AFAIK, that doesn't work yet and the 
nodatacow would apply to all subvolumes on that filesystem, not a good 
idea.  So for now, NOCOW at the directory and file level and dedicated 
subvolume only to prevent snapshotting the NOCOW files, will have to do.)

Also noatime.  That's not btrfs specific, but especially if you're doing 
snapshots it has stronger implications on btrfs than other filesystems.  
Consider, if there hasn't been a whole lot of write activity between 
snapshots, atime updates can be a big part of the difference between one 
snapshot and the last, thus making snapshots far less space efficient 
than they might otherwise be.  So while noatime is always a good option 
to enable unless you're running something (like mutt) that really needs 
them, it's REALLY a good option to enable on btrfs if you're doing 
snapshotting at all.

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

> As long as your memory bandwidth is significantly higher than disk
> bandwidth (which is almost always the case, even with SSD's), this
> should provide at least some improvement with respect to IO involving
> large files.  Because you are using a traditional hard disk instead of
> an SSD, you might get better performance using zlib (assuming you don't
> mind slightly higer processor usage for IO to files larger than the
> leafsize).  If you care less about disk utilization than you do about
> performance, you might want to use compress_force instead of compress,
> as the performance boost comes from not having to write as much data to
> disk.

Agreed.  I'm using compress=lzo here, even on ssd.  I'd probably use zlib 
on spinning rust, and would then experiment with compress-force as well.

The other thing about compress, on a standard single-device filesystem 
with default dup metadata and default single data, is that when I tried 
it here at least (before I got the ssds and went raid1 mode), compress=lzo 
rather nicely offset (and then some, for my use-case) the extra space 
required by the duplicate metadata.

Come to think of it, depending on the compressibility of your data, 
compress=zlib (or possibly compress-force=zlib) might offset much of the 
duplicate space required for mixed-mode dup as well, thereby making it 
more practical.  Since on spinning rust the compression is also likely to 
offset to some degree the slowness of the spinning rust, that might be 
quite a reasonable tradeoff (tho write speeds would still likely be 
noticeably slower than single-data mode due to having to write out both 
copies).

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: BTRFS setup advice for laptop performance ?

[Johannes Hirte]

On Fri, 04 Apr 2014 08:33:10 -0400
Austin S Hemmelgarn <ahferroin7@gmail.com> wrote:

> On 2014-04-04 04:02, Swâmi Petaramesh wrote:
> > - 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...
> This depends on many things, the average size of the files on the disk
> is the biggest factor.  In general you should get the best disk
> utilization by setting nodesize so that a majority of the files are
> less than the leafsize minus 256 bytes, and all but a few are smaller
> than two times the leafsize minus 256 bytes.  However, if you want to
> really benefit from the data compression, you should just use the
> smallest leaf/nodesize for your system (which is what mkfs defaults
> to), as data that gets as BTRFS stores files whose size is at least
> (roughly) 256 bytes less than the leafsize inline with the metadata,
> and doesn't compress such files.

With commit c652e4efb8e2dd76ef1627d8cd649c6af5905902 the default
node-/leafsize has changed:

commit c652e4efb8e2dd76ef1627d8cd649c6af5905902
Author: Chris Mason <chris.mason@fusionio.com>
Date:   Fri Nov 8 13:51:52 2013 -0500

    mkfs: change default metadata blocksize to 16KB

Re: BTRFS setup advice for laptop performance ?

[Hugo Mills]

[-- 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 --]

Re: BTRFS setup advice for laptop performance ?

[Swâmi Petaramesh]

Le vendredi 4 avril 2014 16:09:06 Hugo Mills a écrit :
> 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.

I would have hard times finding what ! I have seen this on each and every 
machine on which I have installed BTRFS over the past 2 years. These first were 
Ubuntus, now there is one Mint, 2 Arch, 1 Fedora, all with decently recent 
kernels and "alls updates applied".

All those machines do "mainly boring office tasks", email, web surf, word 
processing, spreadsheets. No databases except for system packages DB and KDE 
"akonadi" email storage... Few compilations, if any, no heavy disk tasks, all 
mounted with noatime, space_cache, inode_cache, etc...

No torrents, no bitcoins, very seldom used Virtualbox (and this is nocow).

No filesystem is over 80% full, some are below 20%...

No filesystems currently have more than 4 active snapshots.

All get slow like hell over time.

> How are you measuring the slowdown -- do you have a
> specific piece of benchmarking software, or just anecdotal evidence?

When your system slowly shifts from "normally responsive" to "dreadfully slow" 
over time, that starting any app takes over a full minute with HD LED steady 
lit, that booting bhas become so long that the GUI DM dies of timeout before 
it even starts, and you have to restart it manualle... you can tell it's gone 
"sloooooow" without any benchmark figures...

(Disk health good on all machines...)

Go figure...

-- 
Swâmi Petaramesh <swami@petaramesh.org> http://petaramesh.org PGP 9076E32E

Re: BTRFS setup advice for laptop performance ?

[Duncan]

Swâmi Petaramesh posted on Sat, 05 Apr 2014 00:35:08 +0200 as excerpted:

[Multiple machines, multiple distros, all going slow over time, the 
common thread being btrfs on all.]

> All those machines do "mainly boring office tasks", email, web surf,
> word processing, spreadsheets. No databases except for system packages
> DB and KDE "akonadi" email storage... Few compilations, if any, no heavy
> disk tasks, all mounted with noatime, space_cache, inode_cache, etc...

Some things to check:

1)  You don't mention the autodefrag mount option.  That may be part of 
the problem, but be aware that simply turning it on without doing a 
manual defrag first will likely make things even worse until it catches 
up.  A btrfs filesystem defrag -r (recursive, requires a reasonably new 
btrfs-progs) will help if this is the problem, tho on multi-terabyte 
filesystems on spinning rust it can take awhile.  When it's done, turn on 
the autodefrag.  And see point #3 below for specific defrags that might 
help, particularly if you don't want to spend the time to defrag the 
entire system.

2)  There's a reason space_cache is the default but inode_cache is not.  
Unless it's a mail server or something, inode_cache is generally not 
needed, and isn't recommended.  Additionally, I've seen comments to the 
effect that on 32-bit on large multi-terabyte filesystems its pointer can 
wrap, altho I'm not sure that's accurate or of the failure mode if it is, 
and we don't see lots of bug reports from it.  Anyway, the recommendation 
is leave it off unless you know you need it.

3)  I'm a kde-er so the akonadi mention caught my eye, that also being 
the reason I chose the paragraph above to quote.  I'm also a gentooer and 
now have semantic-desktop turned off at build time, and switched from 
kmail to claws-mail when kmail akonadified, so have neither akonadi nor 
nepomuk/baloo on my system at all, now.  (Strigi is still required at 
build time for its headers, but with no backend setup for it and 
everything else turned off, it's effectively only that, no runtime.)

Try turning off as much of semantic-desktop and akonadi as you can, and 
see if you get some speed back.  But note that akonadi in particular can 
be difficult to try to prevent autostarting.  Also, kmail and kontact 
past the kdepim 4.4 series (so kmail 2.x is affected, kmail 1.x not) 
basically won't work without akonadi running.  FWIW that's one reason I'm 
on claws-mail now, but you can first simply shut akonadi down temporarily 
and see if it helps with speed, then decide what to do about it if it 
seems to be contributing to your problem.  

While my experience with it was some versions ago now (I switched to 
claws-mail and killed kmail and akonadi in early kde 4.7), I already had 
nepomuk shut off at runtime, and I wasn't using btrfs at the time (I was 
on reiserfs), either getting rid of akonadi at runtime or purging the 
entire semantic-desktop and akonadi thing from my system, disabling them 
at build time, made a **HUGE** difference in system responsiveness!  It 
was ENTIRELY unexpected on my end (the main benefit I expected was to be 
rid of the dependencies), so while I didn't do any benchmarks, it's 
unlikely all in my head, either.

I compared it to adding a couple cores to my then 4-core (now 6-core) 
CPU, or upgrading from half a gig to four gigs of RAM, for free, or to 
the experience MS users have when they get their machine cleaned and 
suddenly realize all that malware was what was slowing the system down.  
(Did I just compare akonadi to malware... yes I did!)  The difference was 
THAT dramatic!  I'm not saying it'll be /that/ dramatic for /everyone/, 
YMMV as they say, but it's worth investigating, as even if it's not that 
dramatic for you, it might help.

Tying it all back to btrfs, if you find that turning off nepomuk/baloo 
indexing and akonadi do speed things up, consider defragging their 
databases and see if you can then run them with less slowdown.  I don't 
actually remember the size of the akonadi database, and obviously that 
was well before baloo, but before I turned off nepomuk file indexing its 
database would grow to well over two gigs here, definitely well above the 
half to one gig that's the recommended cutoff for NOCOW.  So try 
defragging it, then setting NOCOW[1], and see if that helps.  Obviously 
try the same with the akonadi database, setting nocow if it's larger than 
half a gig and simply letting autodefrag keep it clean if it's below half 
a gig.  It's possible that will get you enough performance back, and with 
the nocow and autodefrag, that it'll stay back, that you can keep running 
them and won't need to resort to the more radical switch away from kmail 
and the other kdepim applications that I did.

---
[1] The above assumes you already know the usual drill on setting 
effective nocow on btrfs.  If you don't...  It must be set before the 
file has content, and the easiest way to do that is to set it on the 
directory, before the files are created in it.

[1a] For existing files, copy/move them into the newly nocow-ed 
directory, being sure to either cross filesystems or use 
--reflink=never when copying, to avoid hard/reflinking a still possibly 
fragmented COW file, so the nocow actually takes.

[1b]  Alternatively, touch a new file to create it as zero size, set it 
nocow, then cat the content into it using redirection:

$ touch /path/to/newfile
$ chattr +C /path/to/newfile
$ cat /old/file/path/oldcopy >| /path/to/newfile

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: BTRFS setup advice for laptop performance ?

[Swâmi Petaramesh]

Le samedi 5 avril 2014 10:12:17 Duncan wrote [excellent performance advice 
about disabling Akonadi in BTRFS etc]:

Thanks Duncan for all this excellent discussion.

However I'm still rather puzzled with a filesystem for which advice is "if you 
want tolerable performance, you have to turn off features that are the default 
with any other FS out there (relatime -> noatime) or you have to quit using 
this database, or you have to fiddle around with esoteric option such as 
disabling COW wich BTW is one of BTRFS most promiment features".

In other words, IMHO the best quality of a filesystem is to handle efficiently my 
workload - which means the FS corresponds to my needs - rather than 
necessitating that I change my workload and habits to adapt to the FS.

Looks a bit like you will have to cut one inch of your toes to fit into your 
brand new shiny shoes, ain't it ?

To put it plain flat clear, even if "relatime" causes writes, every other FS 
out there can cope with it. Even if akonadi is heavy and a disk resource hog, 
any other FS out there can cope with it and still maintain acceptable, usable 
performance.

Having a FS which advice is either to stop using what I'm using, OR to turn of 
or not use some of its key features - snapshots, COW... - which are the only 
reasons to consider using it in the 1st place... Uh.

Well... Buy a new car, let the vendor tell you you shouldn't go to the moutain 
for it isn't adapted, you shouldn't go to the sea as the engine will rust, and 
you shouldn't drive too much in cities as it will smoke too much... and not 
too much motorways either as the motor might heat a bit too much.

I need a filesystem that fits me, I don't want to have to fit my filesystem :-\


-- 
Swâmi Petaramesh <swami@petaramesh.org> http://petaramesh.org PGP 9076E32E

Re: BTRFS setup advice for laptop performance ?

[Duncan]

Swâmi Petaramesh posted on Sat, 05 Apr 2014 13:10:13 +0200 as excerpted:

> Le samedi 5 avril 2014 10:12:17 Duncan wrote [excellent performance
> advice about disabling Akonadi in BTRFS etc]:
> 
> Thanks Duncan for all this excellent discussion.
> 
> However I'm still rather puzzled with a filesystem for which advice is
> "if you want tolerable performance, you have to turn off features that
> are the default with any other FS out there (relatime -> noatime) or you
> have to quit using this database, or you have to fiddle around with
> esoteric option such as disabling COW wich BTW is one of BTRFS most
> promiment features".

> I need a filesystem that fits me, I don't want to have to fit my
> filesystem :-\

In fairness, there are two points to consider.

1)  Btrfs is still relatively immature and there are corner-cases and 
kinks and bugs that haven't been worked out yet.

2) If you're going to compare filesystems, be sure you're comparing like 
features.

In the case of noatime in particular, it's recommended for most 
filesystems these days, with the only reason it's not the default being 
backward compatibility with apps like mutt that depend on atime.

But the reason it's more of a problem on btrfs than on other filesystems 
is PRECISELY because of btrfs' snapshotting feature -- a feature that 
most other filesystems simply don't have, AT ALL.  Thus, if you're going 
to compare btrfs against other filesystems in that regard, since most 
other filesystems don't have the snapshotting feature that makes atime a 
bad idea on btrfs, to compare like to like, you must compare btrfs 
without using snapshotting to other filesystems that don't have the 
feature in the first place, and once you do that, btrfs' behavior with 
relatime or even strict atime isn't all that bad.  It's only when you 
bring in snapshots that it's an issue at all, and most filesystems don't 
even have snapshots, so it's not fair to compare the after all relatively 
small efficiency related recommendation to turn off a legacy-support 
feature in ordered to get better efficiency on a brand new feature, with 
filesystems that don't even have that new feature in the first place.

The exception of course is zfs, which does have snapshotting (and which 
isn't an alternative for me so I've not looked into its details enough to 
know the specifics of its snapshot atime handling).  But if you do the 
research, I'm confident you'll find atime updates have a similar 
efficiency cost in relation to snapshotting there, because atime updates 
/are/ a change, and if they're tracked at all, that change must be 
stored /somewhere/.  Now they may not /mention/ the cost, or perhaps 
their snapshot format is inefficient enough the cost of storing atime 
updates is lost in the overall inefficiency of the design, but the cost 
DOES exist, those metadata changes must be stored SOMEWHERE, and either 
their design is efficient enough that it will show up and thus be a 
factor, or it's inefficient and thus it won't be a factor, one or the 
other.

If it's a bother, just ignore what is after all just a small efficiency 
tweaking hint, and pretend it doesn't matter on btrfs either.  Snapshots 
will be a bit bigger and thus you'll either run out of space for 
additional snapshots and have to delete some a bit sooner, or you'll have 
less room to store the actual data, but you can pretend you never read 
about that slight loss of efficiency and go on using relatime or even 
strictatime, and it shouldn't otherwise affect btrfs much more than it 
affects any other filesystem.  Or just don't use snapshots, if you 
prefer, and again, it shouldn't affect btrfs much more differently than 
it affects other filesystems that don't have the snapshotting feature 
available in the first place.

As for COW, the problems there are two-fold.  To some extent, it's 
inherent in the technology.  But there are certainly optimizations that 
can be had, that btrfs isn't doing at this time.  As the filesystem 
matures, these will no doubt be added, and btrfs will handle larger 
internal-write files rather better than it does now.  Still, given the 
technology, I imagine it'll always be possible to get a bit more 
performance by setting nocow on this type of file, because it /is/ a 
problem that's characteristic of COW filesystems and technology in 
general.

Meanwhile, one of the great things about Linux is that it DOES have all 
these filesystem choices available; it's NOT one-size-fits-all (or two-
sizes, fat and ntfs).  The various filesystems each have their individual 
quirks and are better or worse in specific use-cases, and btrfs is and 
will remain no exception.  While btrfs should eventually mature into a 
reasonable general purpose filesystem, suitable to replace the ext* 
series as such, /just/ like the ext* series, there will still be use-
cases where other filesystems are more specifically suited.  For large 
frequent internal-write files, for example, xfs is I believe the 
recommended filesystem today, and it may well remain so as btrfs replaces 
ext3/4, particularly where other btrfs features such as built-in multiple 
device raidN support aren't needed, and where various limitations such as 
first-write-after-snapshot-is-cow even on otherwise nocow files make 
btrfs snapshots not a particularly useful feature for certain types of 
files.

As for disabling akonadi, it's worth noting that when I did that, I was 
still on reiserfs.  Perhaps that's one of the reasons it made such a big 
difference to me, and that may or may not apply to btrfs or ext3/4 
users.  But given that it /did/ make such a difference to me, it's 
certainly worth a try.  I'm certainly biased given my experience with 
akonadi and will admit just that, but /based/ on that experience, if 
akonadi is in fact another common thread to all those installations along 
with btrfs, then based on my own experience, I'd definitely be pointing 
my finger at it, NOT at btrfs, because I've been very happy with btrfs 
performance, while akonadi... let's just say the fact that I compared it 
to malware says it all.

OTOH, for all I know you only had akonadi on one of those installations 
and just happened to mention it.  Perhaps it had nothing to do with the 
slowdowns.

Fine.  I'd say it's still worth testing if disabling it gets you back 
some of that speed.  But it's your systems not mine, and my experience 
may have in fact been a corner-case that has nothing at all to do with 
yours, so believe and do what you will.

Meanwhile, you /were/ asking for advice and I gave you mine.  If you 
don't like it, treat it as worth what you paid for it (zero).  No skin 
off my nose.  But one more zero-cost bit of advice.  If your btrfs 
experience really is that consistently bad, it doesn't really matter what 
I say or someone else says or our experience or advice, why are you still 
bothering with it?  I certainly wouldn't be, because as you said:

> I need a filesystem that fits me, I don't want to have to fit my
> filesystem :-\

If that's not happening with btrfs, honestly, why are you still using 
it?  That's /exactly/ why I'm not using kmail and akonadi today, after 
nearly a decade of being quite happy with it, and despite the trouble of 
converting to something else.  When it didn't fit my needs, I found 
something that did.  Simple as that.  And if btrfs isn't fitting your 
needs, I'd recommend you do likewise, simple as that.

Tho I do believe it can be made a better match, if you wish to spend the 
time to make it so, which after all your post implied you were in fact 
willing and wanting to do.  Your system; your choice. =:^)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: BTRFS setup advice for laptop performance ?

[Hugo Mills]

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

On Sat, Apr 05, 2014 at 01:10:13PM +0200, Swâmi Petaramesh wrote:
> Le samedi 5 avril 2014 10:12:17 Duncan wrote [excellent performance advice 
> about disabling Akonadi in BTRFS etc]:
> 
> Thanks Duncan for all this excellent discussion.
> 
> However I'm still rather puzzled with a filesystem for which advice is "if you 
> want tolerable performance, you have to turn off features that are the default 
> with any other FS out there (relatime -> noatime) or you have to quit using 
> this database, or you have to fiddle around with esoteric option such as 
> disabling COW wich BTW is one of BTRFS most promiment features".

   OK, a couple of points here:

 - For the things where you should turn CoW off, they're typically
   things like databases that do their _own_ CoW handling or similar
   high-performance reliable transactions/writes, so you generally
   lose very little there.

 - I'm not aware, particularly, of any major differences between
   noatime and relatime in performance on btrfs. (But I may be wrong
   there).

 - Given Duncan's discussion of the performance of the semantic
   desktop, I would suggest turning it off *temporarily* to see if it
   really is where the difficulty lies. If it turns out that it's
   unrelated and things still slow down horribly, then at least we've
   knocked down one theory and need to look elsewhere. If it _is_
   related, then that at least gives us a reproducer for the problem,
   and the people who are skilled in tracking down performance
   problems have something to look at. It also means that you have a
   range of things you know you can try if the problem gets really bad
   (maybe delete the database and rebuild it regularly? mark parts of
   it nodatacow? maybe autodefrag helps? maybe it's something simple
   the authors of the database can change?).

[snip]
> I need a filesystem that fits me, I don't want to have to fit my filesystem :-\

   If you truly find btrfs unusable -- which you've said at various
points in the past -- then I'm not going to suggest that you keep
using it. Maybe something else is genuinely better for you. It's not
in the interests of the btrfs community to recommend that people use
btrfs when it's not appropriate. That said, it would be good to have
your help to try to fix the (apparently quite unusual) problems you're
seeing. Part of that is tracking down which bit of software is
triggering the issues, and helping to identify what the issues
actually are. Sometimes, the hardest problem in fixing bugs is finding
someone who can reproduce the bug and test fixes.

   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
                   --- Ceci n'est pas une pipe:  | ---                   

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

Re: BTRFS setup advice for laptop performance ?

[Swâmi Petaramesh]

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

Hi people :-)

Le samedi 5 avril 2014 15:13:40 Hugo Mills a écrit :
> 
>  - I'm not aware, particularly, of any major differences between
>    noatime and relatime in performance on btrfs. (But I may be wrong
>    there).

It's especially noticeable at first boot in a given day, as "relatime" will 
have atimes updated once a day.

I've noticed that the 1st boot on any given day can be up to 3-4 times longer 
on a BTRFS with "relatime" compared to a btrfs with "noatime". This is 
especially true if snapshots have recently been made.

>  - Given Duncan's discussion of the performance of the semantic
>    desktop, I would suggest turning it off *temporarily* to see if it
>    really is where the difficulty lies.

I'm afraid that this would turn my email off (I used Kmail and it's backing 
store is Akonadi, and non, I don't want to change MUA), and I can't really 
live long without it ;-)

>    (maybe delete the database and rebuild it regularly?

I'm not considering deleting the database. It contains about 1GB of my email 
archive and I've no clue about how I could possibly export and reimport it. 
The way the Kmail apps use the Akonadi backing store is somewhat tricky...

>    mark parts of it nodatacow?

I woud be allright about trying "nodatacow", but it's totally unclear to me 
what impact this can have on snapshots ?

Will "nodatacow" defeat snapshots, allowing data to change in snapshots ?

OTOH will snapshots force datacow to happen, defeating the purpose of 
nodatacow ?

As I don't want to break my DB, I won't use nodatacow until I'm sure about the 
consequences...

>    maybe autodefrag helps?

I've always used autodefrag... Plus I perform manual defrags more often than 
in Windows :-/

>    maybe it's something simple
>    the authors of the database can change?).

I'm not going to expect KDE people to change anything aytime soon upon users 
requests. Some very *SIMPLE* bugs confirmed by dozens of users have stayed in 
their bug tracker for years.

KDE bugs stay until somedays God decides to fix one. If ever.

>    If you truly find btrfs unusable -- which you've said at various
> points in the past -- then I'm not going to suggest that you keep
> using it. Maybe something else is genuinely better for you.

Every 9 months or so I reads reports or reviews or the BTRFS wiki stating that 
performance and stability of BTRFS have dramatically improved. Then I read 
everyting I can about new mkfs or btrfstune options, advice, best mount 
options, the wiki, and give it a try.

Typically a couple months later my machines slow down to the point where I 
come and start complaining here.

Usually 2 more months and I'm back either to ext4 or ZFS, depending on the 
machine's specific usage pattern...

I still think that BTRFS *should* be very promising *if* its developpers can 
fix the recurring performance issues and make it truly usable « for basic 
boring office use » which is currently typically my case on my laptops, and I'm 
no benchmark (or maybe a human one ?) and I can say that currently, BTRFS is 
*not* adapted for a KDE desktop running KMail and Firefox - but if it aint' no 
good at this very basic usage, well what is it good at ?

I'm not ranting because I love to shoot BTRFS down in flames, but because I'd 
love to be able to keep it on my system this time, and forget it, and not to 
reformat everything again in a month or so (as soon as I will tell myself : « 
Well, the improvements promised by kernel 3.14 are still far behind my 
usability needs »)...

Kind regards.

-- 
Swâmi Petaramesh <swami@petaramesh.org> http://petaramesh.org PGP 9076E32E

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 190 bytes --]

Re: BTRFS setup advice for laptop performance ?

[Austin S Hemmelgarn]

On 2014-04-05 07:10, Swâmi Petaramesh wrote:
> Le samedi 5 avril 2014 10:12:17 Duncan wrote [excellent performance advice 
> about disabling Akonadi in BTRFS etc]:
> 
> Thanks Duncan for all this excellent discussion.
> 
> However I'm still rather puzzled with a filesystem for which advice is "if you 
> want tolerable performance, you have to turn off features that are the default 
> with any other FS out there (relatime -> noatime) or you have to quit using 
> this database, or you have to fiddle around with esoteric option such as 
> disabling COW wich BTW is one of BTRFS most promiment features".
> 
The only reason AFAIK that noatime isn't the default on other
filesystems is because it breaks stuff like mutt.  Other than that,
nobody really uses atimes, and noatime will in-fact get you better
performance on any filesystem.
> [...]
> To put it plain flat clear, even if "relatime" causes writes, every other FS 
> out there can cope with it. Even if akonadi is heavy and a disk resource hog, 
> any other FS out there can cope with it and still maintain acceptable, usable 
> performance.
> 
This is because every other filesystem (except ZFS) doesn't use COW
semantics.  IIRC, using those same features on ZFS causes the same
problems.  This in fact brings to mind one of the biggest reasons that I
refuse to use KDE (or systemd for that matter), KDE systems run slower
in my experience even on ext4, XFS, and JFS, not just on COW filesystems.

Re: BTRFS setup advice for laptop performance ?

[Clemens Eisserer]

Hi,

> This is because every other filesystem (except ZFS) doesn't use COW
> semantics.

Nilfs2 also is COW based.

Regards, Clemens

Re: BTRFS setup advice for laptop performance ?

[Austin S Hemmelgarn]

On 2014-04-08 07:56, Clemens Eisserer wrote:
> Hi,
> 
>> This is because every other filesystem (except ZFS) doesn't use COW
>> semantics.
> 
> Nilfs2 also is COW based.
> 
> Regards, Clemens
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
Apologies, I had forgotten about NILFS2 (probably because I choose not
to deal with it due to stability issues that i have experienced, and a
lack of XATTR and ACL support).

Re: BTRFS setup advice for laptop performance ?

[Chris Samuel]

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

On Mon, 7 Apr 2014 11:11:11 AM Austin S Hemmelgarn wrote:

> This is because every other filesystem (except ZFS) doesn't use COW
> semantics.

There is an interesting article on LWN at the moment (subscriber only for the 
next day or two, but if you can afford it I'd suggest considering subscribing) 
about the Linux Storage, Filesystem, and Memory Management (LSFMM) Summit 
discussions around the impact of the new Shingle Magnetic Recording (SMR) 
drives that may change that.

Given these devices are likely to have large sequential write only areas it's 
going to make getting existing Linux filesystems to work on them "interesting", 
in the section on Dave Chinners filesystem part of the discussion it says:

# Any of the existing filesystems that do not support copy-on-write (COW)
# cannot really be optimized for SMR, he said, because you can't overwrite
# data in sequential zones. That would mean adding COW to ext4 and XFS,
# Chinner said. 

https://lwn.net/Articles/592091/

There's some background to SMR drives (available to all) from the LSFMM here:

https://lwn.net/Articles/591782/

All the best,
Chris
-- 
 Chris Samuel  :  http://www.csamuel.org/  :  Melbourne, VIC


[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 482 bytes --]

Re: BTRFS setup advice for laptop performance ?

[Marc MERLIN]

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

On Fri, Apr 04, 2014 at 04:09:06PM +0100, Hugo Mills wrote:
> > - 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.

Speaking of this bit, I once tried to use zlib instead of lzo, and somehow
it felt that my laptop on SSD booted noticeably slower after that, which
felt weird since decompression speed should be about the same.

Has anyone else noticed anything like this?

Marc
-- 
"A mouse is a device used to point at the xterm you want to type in" - A.S.R.
Microsoft is to operating systems ....
                                      .... what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/  

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

Re: BTRFS setup advice for laptop performance ?

[Koen Kooi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Marc MERLIN schreef op 12-04-14 15:17:
> On Fri, Apr 04, 2014 at 04:09:06PM +0100, Hugo Mills wrote:
>>> - 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.
> 
> Speaking of this bit, I once tried to use zlib instead of lzo, and
> somehow it felt that my laptop on SSD booted noticeably slower after
> that, which felt weird since decompression speed should be about the
> same.
> 
> Has anyone else noticed anything like this?

LZO should decompress a lot faster than zlib, I know that's the case on ARM
and 32bit x86.

regards,

Koen

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)
Comment: GPGTools - http://gpgtools.org

iD8DBQFTSXQQMkyGM64RGpERAtTRAJ9WQg0xA3s3AA+jMryzn6PVWpyEegCbBZTR
IzOZtgJvMbLT2fXdw0fOCxQ=
=2FXK
-----END PGP SIGNATURE-----

Re: BTRFS setup advice for laptop performance ?

[Garry T. Williams]

On 4-4-14 10:02:27 Swâmi Petaramesh wrote:
> 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.

Yeah, I have experienced this, too.  I can't say what your experience
was, but mine was all about copy-on-write along with two applications:
akonadi and Web browsers.

I no longer see the slow degradation over time because I made the
following directories recursively nodatacow:

    .local/share/akonadi
    .cache/google-chrome/Default
    .cache/mozilla/firefox/ogtorq5r.default

To do that, I had to copy[*] all of the existing files in those
hierarchies after chattr +C on the directories.

Using btrfs on my home directory has been fine ever since.



______________
[*] Examining my shell history turned up this snippet from that time:

    for i in 0 1 2 3;do
    mv data_$i data_$i.t
    touch data_$i
    chattr +C data_$i
    cp data_$i.t data_$i
    rm data_$i.t
    done

I carefully walked all the directories, while none of the applications
above were running, converting all of the files to +C.  It took a
while as I remember.  :-)

-- 
Garry T. Williams

Re: BTRFS setup advice for laptop performance ?

[Duncan]

Garry T. Williams posted on Sat, 05 Apr 2014 10:26:06 -0400 as excerpted:

> I no longer see the slow degradation over time because I made the
> following directories recursively nodatacow:
> 
>     .local/share/akonadi

...snip...

OK, we now have a second link to akonadi (and browsers) and slowness, 
this one confirmed as nocow helping.  Thanks.  It's on my list to watch 
for and point out when I see it in posts, now.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: BTRFS setup advice for laptop performance ?

[Martin Steigerwald]

Hi,

[not cc´ing you as you didn´t cc anyone and I think you do not like to be CC
´d, note that usual on kernel related mailing lists this is a convention, so I 
may miss it at some time. not restoring other cc´s as I am lazy right now]

Am Samstag, 5. April 2014, 15:06:26 schrieb Duncan:
> Garry T. Williams posted on Sat, 05 Apr 2014 10:26:06 -0400 as excerpted:
> > I no longer see the slow degradation over time because I made the
> > 
> > following directories recursively nodatacow:
> >     .local/share/akonadi
> 
> ...snip...
> 
> OK, we now have a second link to akonadi (and browsers) and slowness,
> this one confirmed as nocow helping.  Thanks.  It's on my list to watch
> for and point out when I see it in posts, now.

I use Akonadi and Nepomuk, long time with, now without mail indexing on a Dual 
SSD BTRFS RAID 1 setup in my laptop. I see performance issues with Akonadi but 
as to what I observed none of these where related to storage.

But I observe, that running this setup for a longer time seems to give hefty 
free space fragmentation, visible by increased fstrim times:

/home: 54407880704 bytes were trimmed
fstrim -v /home  0,00s user 12,25s system 25% cpu 48,062 total

This has almost been instant before.

And this is still good. I redid /home as downsizing the old BTRFS let the 
kernel hang repeatedly. On the old setup, I had a time of several minutes.

On redoing /home I was lazy, and made it single first and converted it to raid1 
for data and metadata. This may have some performance impact, cause last time 
I balanced a BTRFS filesystem the boot time doubled.

That said /home appears to be fast enough for me.

Current setup:

merkaba:~> cat /proc/version
Linux version 3.14.0-tp520 (martin@merkaba) (gcc version 4.8.2 (Debian 
4.8.2-17) ) #52 SMP PREEMPT Mon Mar 31 13:41:48 CEST 2014

Waiting for 3.15-rc2 or so :)

merkaba:~> file -Lsk /dev/sata/home
/dev/sata/home: BTRFS Filesystem label "home", sectorsize 4096, nodesize 
16384, leafsize 16384, UUID=[…], 102075097088/322122547200 bytes used, 2 
devices

That bytes used figure doesn´t seem quite right.

merkaba:~> btrfs fi df /home       
Data, RAID1: total=116.00GiB, used=92.91GiB
System, single: total=4.00MiB, used=48.00KiB
Metadata, RAID1: total=4.00GiB, used=2.15GiB

merkaba:~> btrfs fi show
[…]
Label: home  uuid: […]
        Total devices 2 FS bytes used 95.06GiB
        devid    1 size 150.00GiB used 120.00GiB path /dev/dm-0
        devid    2 size 150.00GiB used 120.00GiB path /dev/mapper/sata-home
[…]

merkaba:~> grep /home /proc/mounts
/dev/dm-0 /home btrfs rw,noatime,compress=lzo,ssd,space_cache 0 0
/dev/dm-0 /mnt/home-zeit btrfs rw,noatime,compress=lzo,ssd,space_cache 0 0


I am unsure about the compress=lzo option. The 300 GB Intel SSD 320 (SATA) 
does not compress, but I bet the 480 GB Crucial m500 (mSATA) does. 

Ciao,
-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7

Re: BTRFS setup advice for laptop performance ?

[Chris Samuel]

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

On Fri, 4 Apr 2014 10:02:27 AM Swâmi Petaramesh wrote:

> 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.

That's odd, I've been running it on laptops with SSDs since 2009 and haven't 
hit this yet.    I'm a KDE user too (though not using Kmail/Akonadi on the 
machines in question).

Sorry I can't do much more than say "works for me", but that happens to be the 
case.. :-(

cheers!
Chris
-- 
 Chris Samuel  :  http://www.csamuel.org/  :  Melbourne, VIC


[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 482 bytes --]