Re: Performance Issues

Hi Everyone, I wrote: > I have a particularly uncomplicated setup (a desktop PC with a hard > disk) and I'm seeing particularly slow performance from btrfs. A `git > status` in the linux source tree takes about 46 seconds after dropping > caches, whereas on other machines using ext4 this takes ab

Re: Performance Issues

On Mon, Sep 22, 2014 at 12:37:59PM +, Holger Hoffstätte wrote: > Thanks Dave - that confirms everything I (unscientifically ;) observed so > far, since I also tried to use "find" to warm up (in the hope it would > cache the relevant metadata blocks), but running with strace showed that > it doe

Re: Performance Issues

On Mon, 22 Sep 2014 13:59:03 +0200, David Sterba wrote: > On Fri, Sep 19, 2014 at 01:34:38PM +, Holger Hoffstätte wrote: >> >> I'd also love a technical explanation why this happens and how it could >> be fixed. Maybe it's just a consequence of how the metadata tree(s) >> are laid out on disk

Re: Performance Issues

On Fri, Sep 19, 2014 at 01:34:38PM +, Holger Hoffstätte wrote: > On Fri, 19 Sep 2014 13:18:34 +0100, Rob Spanton wrote: > > > I have a particularly uncomplicated setup (a desktop PC with a hard > > disk) and I'm seeing particularly slow performance from btrfs. A `git > > status` in the linux

Re: Performance Issues

Hi, Am Samstag 20 September 2014, 22:04:16 schrieb Wang Shilong: > Hi, > > just my two cents here.^_^ > > > Am Freitag, 19. September 2014, 13:51:22 schrieb Holger Hoffstätte: > >> On Fri, 19 Sep 2014 13:18:34 +0100, Rob Spanton wrote: > >>> I have a particularly uncomplicated setup (a desktop

Re: Performance Issues

On Sep 20, 2014, at 7:41 AM, Martin wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 20/09/14 09:23, Marc Dietrich wrote: >> Am Freitag, 19. September 2014, 13:51:22 schrieb Holger >> Hoffstätte: >>> >>> On Fri, 19 Sep 2014 13:18:34 +0100, Rob Spanton wrote: >>> I have a p

Re: Performance Issues

Hi, just my two cents here.^_^ > Am Freitag, 19. September 2014, 13:51:22 schrieb Holger Hoffstätte: >> >> On Fri, 19 Sep 2014 13:18:34 +0100, Rob Spanton wrote: >> >>> I have a particularly uncomplicated setup (a desktop PC with a hard >>> disk) and I'm seeing particularly slow performance fro

Re: Performance Issues

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 20/09/14 09:23, Marc Dietrich wrote: > Am Freitag, 19. September 2014, 13:51:22 schrieb Holger > Hoffstätte: >> >> On Fri, 19 Sep 2014 13:18:34 +0100, Rob Spanton wrote: >> >>> I have a particularly uncomplicated setup (a desktop PC with a >>> har

Re: Performance Issues

Am Freitag, 19. September 2014, 13:51:22 schrieb Holger Hoffstätte: > > On Fri, 19 Sep 2014 13:18:34 +0100, Rob Spanton wrote: > > > I have a particularly uncomplicated setup (a desktop PC with a hard > > disk) and I'm seeing particularly slow performance from btrfs. A `git > > status` in the li

Re: Performance Issues

Rob Spanton posted on Fri, 19 Sep 2014 17:51:09 +0100 as excerpted: > The evolution problem has been improved: the sqlite db that it was using > had over 18000 fragments, so I got evolution to recreate that file with > nocow set. It now takes "only" 30s to load my mail rather than 80s, > which is

Re: Performance Issues

On Fri, Sep 19, 2014 at 01:51:22PM +, Holger Hoffstätte wrote: > > On Fri, 19 Sep 2014 13:18:34 +0100, Rob Spanton wrote: > > > I have a particularly uncomplicated setup (a desktop PC with a hard > > disk) and I'm seeing particularly slow performance from btrfs. A `git > > status` in the lin

Re: Performance Issues

On 09/19/2014 11:51 AM, Rob Spanton wrote: Hi, Thanks for the response everyone. I wrote: I have a particularly uncomplicated setup (a desktop PC with a hard disk) and I'm seeing particularly slow performance from btrfs. A `git status` in the linux source tree takes about 46 seconds after dro

Re: Performance Issues

Hi, Thanks for the response everyone. I wrote: > I have a particularly uncomplicated setup (a desktop PC with a hard > disk) and I'm seeing particularly slow performance from btrfs. A `git > status` in the linux source tree takes about 46 seconds after dropping > caches, whereas on other machine

Re: Performance Issues

On Fri, 19 Sep 2014 10:53:03 -0400, Austin S Hemmelgarn wrote: > I find that kind of funny, because regardless of filesystem, stat() is > one of the *slowest* syscalls on almost every *nix system in existence. Sure. I didn't mean to imply that stat() in its various incarnations is fast by itself

Re: Performance Issues

On 09/19/2014 08:18 AM, Rob Spanton wrote: Hi, I have a particularly uncomplicated setup (a desktop PC with a hard disk) and I'm seeing particularly slow performance from btrfs. A `git status` in the linux source tree takes about 46 seconds after dropping caches, whereas on other machines using

Re: Performance Issues

On 2014-09-19 09:51, Holger Hoffstätte wrote: On Fri, 19 Sep 2014 13:18:34 +0100, Rob Spanton wrote: I have a particularly uncomplicated setup (a desktop PC with a hard disk) and I'm seeing particularly slow performance from btrfs. A `git status` in the linux source tree takes about 46 second

Re: Performance Issues

On Fri, 19 Sep 2014 13:18:34 +0100, Rob Spanton wrote: > I have a particularly uncomplicated setup (a desktop PC with a hard > disk) and I'm seeing particularly slow performance from btrfs. A `git > status` in the linux source tree takes about 46 seconds after dropping > caches, whereas on other

Re: Performance Issues

On Fri, 19 Sep 2014 13:18:34 +0100, Rob Spanton wrote: > I have a particularly uncomplicated setup (a desktop PC with a hard > disk) and I'm seeing particularly slow performance from btrfs. A `git > status` in the linux source tree takes about 46 seconds after dropping > caches, whereas on other

Re: Performance Issues

On 2014-09-19 08:49, Austin S Hemmelgarn wrote: On 2014-09-19 08:18, Rob Spanton wrote: Hi, I have a particularly uncomplicated setup (a desktop PC with a hard disk) and I'm seeing particularly slow performance from btrfs. A `git status` in the linux source tree takes about 46 seconds after dr

Re: Performance Issues

On 2014-09-19 08:25, Swâmi Petaramesh wrote: Le vendredi 19 septembre 2014, 13:18:34 Rob Spanton a écrit : I have a particularly uncomplicated setup (a desktop PC with a hard disk) and I'm seeing particularly slow performance from btrfs. Weeelll I have the same over-complicated kind of setup,

Re: Performance Issues

On 2014-09-19 08:18, Rob Spanton wrote: Hi, I have a particularly uncomplicated setup (a desktop PC with a hard disk) and I'm seeing particularly slow performance from btrfs. A `git status` in the linux source tree takes about 46 seconds after dropping caches, whereas on other machines using ex

Re: Performance Issues

Le vendredi 19 septembre 2014, 13:18:34 Rob Spanton a écrit : > I have a particularly uncomplicated setup (a desktop PC with a hard > disk) and I'm seeing particularly slow performance from btrfs. Weeelll I have the same over-complicated kind of setup, and an Arch Linux BTRFS system which used to

Re: performance issues on btrfs after many snaps

thanks chris. Is this a source base that I can try to reproduce these performance problems with? no. unfortunately not. I can give my workflow script (a few python lines). Over the weekend, I'll try to switch it to build the linux kernel over consecutive changes. The first question woul

Re: performance issues on btrfs after many snaps

On Thu, 2009-04-02 at 09:33 -0700, Anupam Garg wrote: > I'm trying to do some incremental product builds on btrfs. > My general workflow is: > > for CLN in CHANGES: > (1) sync CLN in /btrfs/current > (2) build > (3) if btrfs_with_snapshots: snap to /btrfs/CLN > > I tried 3 ways: > ext