From: Marc MERLIN <marc@merlins.org>
To: Mitch Harder <mitch.harder@sabayonlinux.org>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: zlib vs lzo uncompress speed, ssd vs nossd
Date: Wed, 27 Mar 2013 14:22:55 -0700 [thread overview]
Message-ID: <20130327212255.GF17613@merlins.org> (raw)
In-Reply-To: <CAKcLGm98D1H4oMnN8+Sc8tbC8dCh=gwUQL9vw7M1pmQOn78Epw@mail.gmail.com>
On Wed, Mar 27, 2013 at 04:12:27PM -0500, Mitch Harder wrote:
> On Wed, Mar 27, 2013 at 11:53 AM, Marc MERLIN <marc@merlins.org> wrote:
> >
> > Is my feeling of slower boot wrong, or is zlib also noticeably slower than
> > lzo to read and decompress?
> >
>
> Lzo compression should be faster in every aspect than zlib, especially
> for reading.
>
> But having said that, btrfs won't recompress any existing files just
> because you switch your mount option from lzo to zlib. Only newly
> written files will be zlib, and btrfs will leave the lzo-compressed
> files alone unless they are re-written, or you expressly recompress
> them using the defrag tool.
That was my intent at the time, I thought that zlib decompression was about
as fast as lzo, so it would have been good that most my files stayed
compressed as zlib.
Turns out I was wrong :)
> If you were to take a snapshot of your root partition, and reboot to
> the snapshot as the new root with zlib compression, you could make
> some side-by-side comparisons of boot time to clarify your
> impressions.
Fair point. By that, you mean degrag all my files somehow (recompressing as
lzo, and doubling the size of my rootfs)?
Also, I was re-reading ssd vs nossd:
https://btrfs.wiki.kernel.org/index.php/Mount_options
isn't clear whether these are read/write ordering optimizations, or
filesystem layout optimization (i.e. you'd have to recreate the entire FS,
and rewrite everything).
http://www.phoronix.com/scan.php?page=article&item=btrfs_ssd_mode&num=1
says 'However, unless disabling the write cache for the drive, the SSD mode
does not necessarily mean better performance. In fact, as our results are
about to show, the quantitative disk performance can drop greatly in the SSD
mode when the write cache remains enabled'
But that's from 2009, so not very relevant to today.
Do you happen to know more than me on 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/
next prev parent reply other threads:[~2013-03-27 21:22 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-27 16:53 zlib vs lzo uncompress speed, ssd vs nossd Marc MERLIN
2013-03-27 21:12 ` Mitch Harder
2013-03-27 21:22 ` Marc MERLIN [this message]
2013-03-27 21:33 ` Mitch Harder
2013-03-27 21:26 ` Marc MERLIN
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=20130327212255.GF17613@merlins.org \
--to=marc@merlins.org \
--cc=linux-btrfs@vger.kernel.org \
--cc=mitch.harder@sabayonlinux.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox