BTRFS setup advice for laptop performance ?

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 <[email protected]> http://petaramesh.org PGP 9076E32E

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

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.

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

Unless you are using stuff like QEMU or Virtualbox, you should probably have autodefrag and space_cache on from the very start.

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.

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 <[email protected]> http://petaramesh.org PGP 9076E32E

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 /)

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

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

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

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.

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

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.

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!

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.

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

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

commit c652e4efb8e2dd76ef1627d8cd649c6af5905902

Author: Chris Mason <[email protected]>
Date:   Fri Nov 8 13:51:52 2013 -0500

mkfs: change default metadata blocksize to 16KB

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?

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.

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.

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.

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.

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?                     

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.

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 <[email protected]> http://petaramesh.org PGP 9076E32E

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

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

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 <[email protected]> http://petaramesh.org PGP 9076E32E

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

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

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

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]

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

Hi people :-)

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.

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 ;-)

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

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

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

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.

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 <[email protected]> http://petaramesh.org PGP 9076E32E

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.

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.

Hi,

Nilfs2 also is COW based.

Regards, Clemens

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

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

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/  

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

Marc MERLIN schreef op 12-04-14 15:17:

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

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

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

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

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:

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

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