linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mitch Harder <mitch.harder@sabayonlinux.org>
To: Marc MERLIN <marc@merlins.org>
Cc: Hugo Mills <hugo@carfax.org.uk>, Duncan <1i5t5.duncan@cox.net>,
	linux-btrfs <linux-btrfs@vger.kernel.org>
Subject: Re: raid0 vs single, and should we allow -mdup by default on SSDs?
Date: Wed, 7 May 2014 17:39:18 -0500	[thread overview]
Message-ID: <CAKcLGm9gJ0ZRwp_h=AtP8ArdC7Yuq_Cspxg=23FS4reazO6R+g@mail.gmail.com> (raw)
In-Reply-To: <20140507085240.GN10159@merlins.org>

On Wed, May 7, 2014 at 3:52 AM, Marc MERLIN <marc@merlins.org> wrote:
> On Wed, May 07, 2014 at 09:29:41AM +0100, Hugo Mills wrote:
>> On Wed, May 07, 2014 at 01:18:40AM -0700, Marc MERLIN wrote:
>> > On Tue, May 06, 2014 at 07:39:12PM +0000, Duncan wrote:
>> > > That appears to be a very good use of either -d raid0 or -d single, yes.
>> > > And since you're apparently not streaming such high resolution video that
>> > > you NEED the raid0, single does indeed give you a somewhat better chance
>> > > at recovery.
>> >
>> > zoneminder saves 'video' as a stream of independent small jpegs, so I'm
>> > good. Actually come to think of it they're so small that they probably
>> > all ended up in the raid1 metadata. That also means that I'm not getting
>> > twice the storage space like I planned to. Oh well...
>>
>>    There's a mount option to change the threshold at which files are
>> inlined in metadata: maxinline=<bytes>. You could play with that for
>> this particular use-case.
>
> Oh cool, thank you.
>

Since each non-inlined file will occupy a minimum of 4k, you may find
that inlining will still save space even if it is duplicated.

Even if they are duplicated in the metadata under RAID1, inlining a
bunch of 256 byte files will still be more space efficient than
storing them as regular files.

But if most of the files are in the 2k-3k range, you may be more
efficient to store them as files.

  reply	other threads:[~2014-05-07 22:39 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-03 23:27 Is metadata redundant over more than one drive with raid0 too? Marc MERLIN
2014-05-04  6:57 ` Brendan Hide
2014-05-04  7:24   ` Marc MERLIN
2014-05-04  7:44     ` Brendan Hide
2014-05-05  1:27       ` Marc MERLIN
2014-05-06 19:05         ` Duncan
2014-05-06 19:39         ` Duncan
2014-05-05  0:46     ` Daniel Lee
2014-05-05  5:06       ` Marc MERLIN
2014-05-06 17:16         ` Duncan
2014-05-07  8:18           ` raid0 vs single, and should we allow -mdup by default on SSDs? Marc MERLIN
2014-05-07  8:29             ` Hugo Mills
2014-05-07  8:52               ` Marc MERLIN
2014-05-07 22:39                 ` Mitch Harder [this message]
2014-05-04 21:49 ` Is metadata redundant over more than one drive with raid0 too? Duncan

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='CAKcLGm9gJ0ZRwp_h=AtP8ArdC7Yuq_Cspxg=23FS4reazO6R+g@mail.gmail.com' \
    --to=mitch.harder@sabayonlinux.org \
    --cc=1i5t5.duncan@cox.net \
    --cc=hugo@carfax.org.uk \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=marc@merlins.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;
as well as URLs for NNTP newsgroup(s).