public inbox for linux-btrfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Chris Mason <chris.mason@oracle.com>
To: Jim Faulkner <jfaulkne@ccs.neu.edu>
Cc: Josef Bacik <josef@redhat.com>, linux-btrfs@vger.kernel.org
Subject: Re: worse than expected compression ratios with -o compress
Date: Thu, 21 Jan 2010 15:05:41 -0500	[thread overview]
Message-ID: <20100121200541.GB23006@think> (raw)
In-Reply-To: <alpine.DEB.2.00.1001211224530.19136@alumni-linux.ccs.neu.edu>

On Thu, Jan 21, 2010 at 01:16:31PM -0500, Jim Faulkner wrote:
> delta-9 ~ # mount -o noatime,noacl,compress-force /dev/sdi /var/news/mysql
> delta-9 ~ # time cp -a /nfs/media/tmp/btrfs-mysql-test /var/news/mysql/
> 
> real    14m45.742s
> user    0m0.547s
> sys     1m30.551s
> delta-9 ~ # df -h
> Filesystem            Size  Used Avail Use% Mounted on
> /dev/sdi              187G   14G  173G   8% /var/news/mysql
> delta-9 ~ # cd /var/news/mysql
> delta-9 mysql # du -h --max-depth=1
> 73G     ./btrfs-mysql-test
> 73G     .
> delta-9 mysql #
> 
> Wow!  So not only did mount -o compress-force achieve a 19%
> compression ratio, using 53 GB less disk space than mount -o
> compress, it managed to copy the data in only 15 minutes, compared
> to 57 minutes with mount -o compress.
> 
> The disk in question is an old IDE disk in a cheap external USB 2.0
> enclosure, which is probably not exactly the type of storage that
> btrfs is being developed for.  Nevertheless, it is nice to see such
> a huge improvement in the time required to copy the data around.
> 
> I'd be very happy to see the -o compress-force option in the
> mainline kernel someday!

Great, it is working here so I'll queue it up as well.

The performance improvement just comes from writing less to the disk.
Your first run copied 67GB in 57m6s, which comes out to about 20MB/s
write throughput.

Your compress-force run copied 14GB in 14m45s, which gives us
around 16 or 17MB/s (depending on df rounding).  So, we either lost a
little drive throughput due to overhead in the compression code or the
run was totally CPU bound.

If you look at the output from 'time' the two runs appear to be using
the same amount of system time (cpu time in the kernel).  But, most of
the compression is done by helper threads, so the cpu time spent
compressing data doesn't show up.

Just a quick clarification that we didn't make your drive faster, we
just traded CPU for disk.  Most of the time that's a safe trade,
especially when you put usb and ide into the same sentence ;)

Either way, thanks for testing this out.  Do you happen to remember how
small the file becomes when you just plain gzip it?

-chris


  parent reply	other threads:[~2010-01-21 20:05 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-01-16 16:16 worse than expected compression ratios with -o compress Jim Faulkner
2010-01-17 14:34 ` Sander
2010-01-18 14:46   ` Jim Faulkner
2010-01-18 16:06     ` Jim Faulkner
2010-01-18 14:12 ` Josef Bacik
2010-01-18 21:29   ` Chris Mason
2010-01-18 22:11     ` Jim Faulkner
2010-01-20 16:30       ` Chris Mason
2010-01-21 18:16         ` Jim Faulkner
2010-01-21 20:04           ` Gregory Maxwell
2010-01-21 20:07             ` Chris Mason
2010-01-21 20:05           ` Chris Mason [this message]
2010-01-21 22:38             ` Jim Faulkner

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=20100121200541.GB23006@think \
    --to=chris.mason@oracle.com \
    --cc=jfaulkne@ccs.neu.edu \
    --cc=josef@redhat.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox