From: Amon Ott <a.ott@m-privacy.de>
To: ceph-devel@vger.kernel.org
Subject: Re: Ceph on btrfs 3.4rc
Date: Mon, 30 Apr 2012 12:54:31 +0200 [thread overview]
Message-ID: <201204301254.32510.a.ott@m-privacy.de> (raw)
In-Reply-To: <CAJafhzT8D9Hk0atMRWQpCK5Gr_=O+XqMEkPKQzCr351Gf+v3_Q@mail.gmail.com>
On Monday 30 April 2012 wrote Christian Brunner:
> Metadata fragmentation was a big problem (for us) in the past. With
> the "big metatdata feature" (mkfs.btrfs -l 64k -n 64k) these problems
> seem to be solved. We do not use it in production yet, but my stress
> test didn't show any degradation. The only remaining issues I've seen
> are these warnings.
Where exactly are the metadata stored, in the leaf (-l 64k) or in the node (-n
64k)? I would like to avoid wasting space and disk bandwidth and only use one
of these options, if that makes sense.
After reading the short man page I would have tried -n.
Amon Ott
--
Dr. Amon Ott
m-privacy GmbH Tel: +49 30 24342334
Am Köllnischen Park 1 Fax: +49 30 24342336
10179 Berlin http://www.m-privacy.de
Amtsgericht Charlottenburg, HRB 84946
Geschäftsführer:
Dipl.-Kfm. Holger Maczkowsky,
Roman Maczkowsky
GnuPG-Key-ID: 0x2DD3A649
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
prev parent reply other threads:[~2012-04-30 11:04 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-04-20 15:09 Ceph on btrfs 3.4rc Christian Brunner
2012-04-23 7:20 ` Christian Brunner
2012-04-24 15:21 ` Josef Bacik
2012-04-24 16:26 ` Sage Weil
2012-04-24 17:33 ` Josef Bacik
2012-04-24 17:41 ` Neil Horman
2012-04-25 11:28 ` Christian Brunner
2012-04-25 12:16 ` João Eduardo Luís
2012-04-27 11:02 ` Christian Brunner
2012-05-03 14:13 ` Josef Bacik
2012-05-03 15:17 ` Josh Durgin
2012-05-03 15:20 ` Josef Bacik
2012-05-03 16:38 ` Josh Durgin
2012-05-03 19:49 ` Josef Bacik
2012-05-04 20:24 ` Christian Brunner
2012-05-09 20:25 ` Josef Bacik
2012-05-10 17:40 ` Josef Bacik
2012-05-10 20:35 ` Josef Bacik
2012-05-11 13:31 ` Josef Bacik
2012-05-11 18:33 ` Martin Mailand
2012-05-11 19:16 ` Josef Bacik
2012-05-14 14:19 ` Martin Mailand
2012-05-14 14:20 ` Josef Bacik
2012-05-16 19:20 ` Josef Bacik
2012-05-17 10:29 ` Martin Mailand
2012-05-17 14:43 ` Josef Bacik
2012-05-17 15:12 ` Martin Mailand
2012-05-17 19:43 ` Josef Bacik
2012-05-17 20:54 ` Christian Brunner
2012-05-17 21:18 ` Martin Mailand
2012-05-18 14:48 ` Josef Bacik
2012-05-18 17:24 ` Martin Mailand
2012-05-18 19:01 ` Josef Bacik
2012-05-18 20:11 ` Martin Mailand
2012-05-21 3:59 ` Miao Xie
2012-05-22 10:29 ` Christian Brunner
2012-05-22 17:33 ` Josef Bacik
2012-05-23 12:34 ` Christian Brunner
2012-05-23 14:12 ` Josef Bacik
2012-05-23 15:02 ` Josef Bacik
2012-05-23 19:12 ` Martin Mailand
2012-05-24 6:03 ` Martin Mailand
2012-05-24 9:37 ` Christian Brunner
2012-05-22 13:31 ` Josef Bacik
2012-05-11 13:46 ` Christian Brunner
2012-04-29 21:09 ` tsuna
2012-04-30 10:28 ` Christian Brunner
2012-04-30 10:54 ` Amon Ott [this message]
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=201204301254.32510.a.ott@m-privacy.de \
--to=a.ott@m-privacy.de \
--cc=ceph-devel@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