From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <gentoo-user+bounces-140615-garchives=archives.gentoo.org@lists.gentoo.org>
Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80])
by finch.gentoo.org (Postfix) with ESMTP id C48E51381F4
for <garchives@archives.gentoo.org>; Tue, 14 Aug 2012 20:20:32 +0000 (UTC)
Received: from pigeon.gentoo.org (localhost [127.0.0.1])
by pigeon.gentoo.org (Postfix) with SMTP id 4622621C081;
Tue, 14 Aug 2012 20:20:03 +0000 (UTC)
Received: from mail-bk0-f53.google.com (mail-bk0-f53.google.com [209.85.214.53])
by pigeon.gentoo.org (Postfix) with ESMTP id 9F8E721C05F
for <gentoo-user@lists.gentoo.org>; Tue, 14 Aug 2012 20:17:49 +0000 (UTC)
Received: by bkwj4 with SMTP id j4so381286bkw.40
for <gentoo-user@lists.gentoo.org>; Tue, 14 Aug 2012 13:17:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20120113;
h=mime-version:in-reply-to:references:date:message-id:subject:from:to
:content-type;
bh=v02myxfZswX+A1X6WhbeqdRYMiSZPoQxQ871nj3tGHs=;
b=DFMxPAqE4+Oeac1ZEXM8qy5WxDqbnKbPRuiHd9rye66UQ8YbcBtke3a6AT/0f8/N9S
JdIpUZ6fOkEhWcmtT4GXHZtRQuhBmy2hlJdH3iunSS4d2HQ5IK1evY3K14TDMkxYPyEK
QC1FWUOuvdN3xo1Mrzetm+2wxwfMQS5DTnQJ1uNZ35GFsEps5g+8lGkPa61aUn8bQNln
UvW7Br3+qD0uqpdvIHnIr/Uy3Q4ZoE7pMIso1hgXjEBgyNpsjkZO8AuaDXffG8Iw6Oov
h54J2/Snf8/hQsg6sSgATCBRyS3iWrSJeRE3mgWAitXSYkp4+nvcrpbmeQGcM1MihiS2
zQOA==
Precedence: bulk
List-Post: <mailto:gentoo-user@lists.gentoo.org>
List-Help: <mailto:gentoo-user+help@lists.gentoo.org>
List-Unsubscribe: <mailto:gentoo-user+unsubscribe@lists.gentoo.org>
List-Subscribe: <mailto:gentoo-user+subscribe@lists.gentoo.org>
List-Id: Gentoo Linux mail <gentoo-user.gentoo.org>
X-BeenThere: gentoo-user@lists.gentoo.org
Reply-to: gentoo-user@lists.gentoo.org
MIME-Version: 1.0
Received: by 10.204.133.193 with SMTP id g1mr6838025bkt.2.1344975468645; Tue,
14 Aug 2012 13:17:48 -0700 (PDT)
Received: by 10.205.25.8 with HTTP; Tue, 14 Aug 2012 13:17:48 -0700 (PDT)
In-Reply-To: <CAKkyAYb5D856vvrj6CjTXpj3fzGOKXLCR6ap3NSjcCo=YprKmg@mail.gmail.com>
References: <CADPZhuoH2fhFcgMJHdGLXHp7rzgEWBcWeeccaDHTxEhry1pDiA@mail.gmail.com>
<CAA2qdGXB-v2T3euBsmmn44BMOUVg8BWFxh4ocfQ5mijhDfLOcg@mail.gmail.com>
<CAGSnHaCd_1Ki+v8yrKuZ-C9TxBe6wXWcjtf3yhnKcNDNSFsXcA@mail.gmail.com>
<2915543.UzKMyIEiK0@energy>
<502A8FD9.5030505@hadt.biz>
<CAKkyAYb5D856vvrj6CjTXpj3fzGOKXLCR6ap3NSjcCo=YprKmg@mail.gmail.com>
Date: Tue, 14 Aug 2012 16:17:48 -0400
Message-ID: <CA+czFiDhF+=rfSMPtf_4N4DkByBWd8bO9jvx6oc31KQuMW_vpA@mail.gmail.com>
Subject: Re: [gentoo-user] Fast file system for cache directory with lot's of files
From: Michael Mol <mikemol@gmail.com>
To: gentoo-user@lists.gentoo.org
Content-Type: multipart/alternative; boundary=0015175dd6f00a4c2904c73f81ef
X-Archives-Salt: 4c6561c7-680c-4e92-ba41-80de849bef64
X-Archives-Hash: 85b850d16174ddb1873e48ba1fd4bbfe
--0015175dd6f00a4c2904c73f81ef
Content-Type: text/plain; charset=UTF-8
On Tue, Aug 14, 2012 at 3:55 PM, Alecks Gates <alecks.g@gmail.com> wrote:
> On Tue, Aug 14, 2012 at 12:50 PM, Michael Hampicke <gentoo-user@hadt.biz>
> wrote:
> > Am 14.08.2012 19:42, schrieb Volker Armin Hemmann:
> >> Am Dienstag, 14. August 2012, 13:21:35 schrieb Jason Weisberger:
> >>> Sure, but wouldn't compression make write operations slower? And
> isn't he
> >>> looking for performance?
> >>
> >> not really. As long as the CPU can compress faster than the disk can
> write
> >> stuff.
> >>
> >> More interessting: is btrfs trying to be smart - only compressing
> compressible
> >> stuff?
> >>
> >
> > It does do that, but letting btrfs check if the files are already
> > compressed, if you know, that they are compressed, is a waste of cpu
> > cycles :)
> >
>
> Also look into the difference between compress and compress-force[0].
> I wonder how much overhead checking whether or not to compress a file
> costs. I use mount options similar to Helmut and get great results:
> defaults,autodefrag,space_cache,compress=lzo,subvol=@,relatime
>
> But most of my data is compressible. Compression makes such a huge
> difference, it surprises me. Apparently on this Ubuntu system it
> automatically makes use of all files on / as a subvolume in "@".
> Interesting.
>
Huge difference, how?
Could we see some bonnie++ comparisons between the various configurations
we've discussed for ext4 and btrfs? Depending on the results, it might be
getting time for me to take the plunge myself.
--
:wq
--0015175dd6f00a4c2904c73f81ef
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div class=3D"gmail_quote">On Tue, Aug 14, 2012 at 3:55 PM, Alecks Gates <s=
pan dir=3D"ltr"><<a href=3D"mailto:alecks.g@gmail.com" target=3D"_blank"=
>alecks.g@gmail.com</a>></span> wrote:<br><blockquote class=3D"gmail_quo=
te" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"=
>
<div class=3D"HOEnZb"><div class=3D"h5">On Tue, Aug 14, 2012 at 12:50 PM, M=
ichael Hampicke <<a href=3D"mailto:gentoo-user@hadt.biz">gentoo-user@had=
t.biz</a>> wrote:<br>
> Am 14.08.2012 19:42, schrieb Volker Armin Hemmann:<br>
>> Am Dienstag, 14. August 2012, 13:21:35 schrieb Jason Weisberger:<b=
r>
>>> Sure, but wouldn't compression make write operations slowe=
r? =C2=A0And isn't he<br>
>>> looking for performance?<br>
>><br>
>> not really. As long as the CPU can compress faster than the disk c=
an write<br>
>> stuff.<br>
>><br>
>> More interessting: is btrfs trying to be smart - only compressing =
compressible<br>
>> stuff?<br>
>><br>
><br>
> It does do that, but letting btrfs check if the files are already<br>
> compressed, if you know, that they are compressed, is a waste of cpu<b=
r>
> cycles :)<br>
><br>
<br>
</div></div>Also look into the difference between compress and compress-for=
ce[0].<br>
I wonder how much overhead checking whether or not to compress a file<br>
costs. =C2=A0I use mount options similar to Helmut and get great results:<b=
r>
defaults,autodefrag,space_cache,compress=3Dlzo,subvol=3D@,relatime<br>
<br>
But most of my data is compressible. =C2=A0Compression makes such a huge<br=
>
difference, it surprises me. =C2=A0Apparently on this Ubuntu system it<br>
automatically makes use of all files on / as a subvolume in "@".<=
br>
Interesting.<br></blockquote><div><br></div><div>Huge difference, how?</div=
><div><br></div><div>Could we see some bonnie++ comparisons between the var=
ious configurations we've discussed for ext4 and btrfs? Depending on th=
e results, it might be getting time for me to take the plunge myself.</div>
</div><div><br></div>-- <br>:wq<br>
--0015175dd6f00a4c2904c73f81ef--