All of lore.kernel.org
 help / color / mirror / Atom feed
From: Goffredo Baroncelli <kreijack@inwind.it>
To: Martin Steigerwald <Martin@lichtvoll.de>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: speeding up slow btrfs filesystem
Date: Fri, 16 Dec 2011 19:38:32 +0100	[thread overview]
Message-ID: <4906354.Rn8tlOeHyD@venice> (raw)
In-Reply-To: <201112161854.46717.Martin@lichtvoll.de>

On Friday, 16 December, 2011 18:54:46 you wrote:
> Am Freitag, 16. Dezember 2011 schrieb Martin Steigerwald:
> > Its not critical for me to fix these issues (soon), but I am curious
> > whether its possible to get the filesystem speedier by some
> > maintenance.
> 
> Maybe after it is clear why it is so slow in the first place ;).

I had the same experience. apt-get upgrade was a frustrating experience!

IIRC the copy-on-write file-system in order to have good performance have to 
merge the write requests most as possible.

Instead apt-get makes a lot of sync calls which don't allow btrfs to merge the 
write requests. This explains why btrfs is slow in this case.

I found a solution, but requires a bit of setup.

The idea is to avoid do perform sync during the package installation. In order 
to avoid data loss in case of failure, I create a snapshot before the 
upgrading. If something goes wrong (i.e. a power failure) I rebooot the system 
from the snapshot. If the installation finish without problem, I flush all the 
data to the disk and remove the snapshot.

For the detail, see a my old post titled "[RFC] aptitude & BTRFS slow" 
(2011-10-19)

BR
G.Baroncelli




-- 
gpg key@ keyserver.linux.it: Goffredo Baroncelli (ghigo) <kreijack@inwind.it>
Key fingerprint = 4769 7E51 5293 D36C 814E  C054 BF04 F161 3DC5 0512

  reply	other threads:[~2011-12-16 18:38 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-12-16 17:51 speeding up slow btrfs filesystem Martin Steigerwald
2011-12-16 17:54 ` Martin Steigerwald
2011-12-16 18:38   ` Goffredo Baroncelli [this message]
2011-12-16 19:53     ` Martin Steigerwald
2011-12-16 20:58       ` Martin Steigerwald
2011-12-17  7:03         ` Sergei Trofimovich
2011-12-17 11:09           ` Martin Steigerwald
2011-12-17 11:26             ` Hugo Mills
2011-12-17 11:38               ` Martin Steigerwald
2011-12-17 11:45                 ` Hugo Mills
2011-12-17 11:57                   ` Martin Steigerwald
2011-12-17 16:35                   ` Martin Steigerwald
2011-12-17 17:27                     ` Hugo Mills
2011-12-17 11:39       ` Goffredo Baroncelli
2011-12-18 18:41     ` Andrea Gelmini
2011-12-20 19:46       ` Goffredo Baroncelli
2011-12-17 11:11 ` Chris Samuel
2011-12-17 12:00   ` Martin Steigerwald
2011-12-17 12:42     ` David McBride
2011-12-17 16:14       ` Martin Steigerwald
  -- strict thread matches above, loose matches on Subject: below --
2011-12-17 11:54 Martin Steigerwald
2011-12-17 12:02 ` Martin Steigerwald
2011-12-17 12:50 ` Goffredo Baroncelli
2011-12-17 16:10   ` Martin Steigerwald

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4906354.Rn8tlOeHyD@venice \
    --to=kreijack@inwind.it \
    --cc=Martin@lichtvoll.de \
    --cc=linux-btrfs@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.