Re: BTRFS setup advice for laptop performance ?
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/ signature.asc Description: Digital signature
Re: BTRFS setup advice for laptop performance ?
-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- -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: BTRFS setup advice for laptop performance ?
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 signature.asc Description: This is a digitally signed message part.
Re: BTRFS setup advice for laptop performance ?
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 signature.asc Description: This is a digitally signed message part.
Re: BTRFS setup advice for laptop performance ?
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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: BTRFS setup advice for laptop performance ?
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 majord...@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). -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: BTRFS setup advice for laptop performance ?
On Fri, 04 Apr 2014 08:33:10 -0400 Austin S Hemmelgarn ahferro...@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.ma...@fusionio.com Date: Fri Nov 8 13:51:52 2013 -0500 mkfs: change default metadata blocksize to 16KB -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: BTRFS setup advice for laptop performance ?
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. -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: BTRFS setup advice for laptop performance ?
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 sw...@petaramesh.org http://petaramesh.org PGP 9076E32E signature.asc Description: This is a digitally signed message part.
Re: BTRFS setup advice for laptop performance ?
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 devid1 size 150.00GiB used 120.00GiB path /dev/dm-0 devid2 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 -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: BTRFS setup advice for laptop performance ?
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
Re: BTRFS setup advice for laptop performance ?
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 sw...@petaramesh.org http://petaramesh.org PGP 9076E32E -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: BTRFS setup advice for laptop performance ?
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
Re: BTRFS setup advice for laptop performance ?
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: | --- signature.asc Description: Digital signature
Re: BTRFS setup advice for laptop performance ?
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 -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: BTRFS setup advice for laptop performance ?
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 -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: BTRFS setup advice for laptop performance ?
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. -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: BTRFS setup advice for laptop performance ?
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 sw...@petaramesh.org http://petaramesh.org PGP 9076E32E -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: BTRFS setup advice for laptop performance ?
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? signature.asc Description: Digital signature
Re: BTRFS setup advice for laptop performance ?
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 /) -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: BTRFS setup advice for laptop performance ?
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
Re: BTRFS setup advice for laptop performance ?
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 sloow without any benchmark figures... (Disk health good on all machines...) Go figure... -- Swâmi Petaramesh sw...@petaramesh.org http://petaramesh.org PGP 9076E32E -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
