linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Freddie Cash <fjwcash@gmail.com>
To: Hubert Kario <hka@qbs.com.pl>
Cc: Kaspar Schleiser <kaspar@schleiser.de>, linux-btrfs@vger.kernel.org
Subject: Re: Synching a Backup Server
Date: Tue, 25 Jan 2011 09:59:39 -0800	[thread overview]
Message-ID: <AANLkTim+3+aHoX0Shc5_Fzym6_xsLAKyEA6c352nCPuD@mail.gmail.com> (raw)
In-Reply-To: <201101251843.21037.hka@qbs.com.pl>

On Tue, Jan 25, 2011 at 9:43 AM, Hubert Kario <hka@qbs.com.pl> wrote:
> Besides, I don't see *why* this should be done...
>
> And as far as I know ZFS doesn't support different reduncancy levels for
> different files residing in the same directory. You can have
> ~/1billion$-project.tar.gz with triple redundancy and ~/temp.video.mkv with no
> reduncancy with btrfs...

With ZFS, redundancy (mirror, raidz1, raidz2, raidz3) is done at the
storage pool layer, and affects the entire pool.  You can mix and
match redundancy levels (combine mirror vdevs and raidz vdevs in the
same pool), but there's no way to control what data blocks go to which
vdev, as it's all just one giant pool of storage.

However, there is a "copies" property for each filesystem that affects
how many copies of data blocks are stored, to increase the redundancy
for that filesystem.  For example, you can create a storage pool using
2 mirror vdevs (4 drives; equivalent to a RAID10 setup); then create a
filesystem with copies=2.  Thus, any blocks written to that filesystem
will be stored twice, each of which is then striped across the two
vdevs, and then mirrored to each disk in the vdevs, potentially
leading to 4 (or more) blocks of data written to disk.

This is similar to using Linux md to create RAID arrays underneath LVM
volume groups.  The redundancy is managed via md; the filesystems just
see a collection of blocks to write to.

The big difference (from what I understand) between ZFS and Btrfs is
the layering.  ZFS separate storage management from filesystem
management, so redundancy happens at lower layers and the filesystem
just sends blocks to the pool.  Whereas Btrfs combines them into one,
so that redundancy is managed at the filesystem level and can be
changed on a per-directory (or per-sub-volume?) basis, with the
filesystem handling the writes and the redundancy.

I don't pretend to understand all the intricacies of how Btrfs works
(I'm working on it), but the layering in ZFS is very nice and easy to
work with in comparison.  Interesting how ZFS is considered the
"rampant layering violation", though.  ;)  :)  :D

-- 
Freddie Cash
fjwcash@gmail.com

  reply	other threads:[~2011-01-25 17:59 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-01-06 17:35 Synching a Backup Server Carl Cook
2011-01-06 19:16 ` Freddie Cash
2011-01-06 19:34   ` Marcin Kuk
     [not found]   ` <AANLkTik-rhXAHW18id4WMMtdqXkicvzTZ47+2r6YMuY0@mail.gmail.com>
2011-01-06 19:47     ` Freddie Cash
2011-01-06 20:07       ` C Anthony Risinger
2011-01-06 20:13         ` Freddie Cash
2011-01-06 20:21           ` C Anthony Risinger
2011-01-06 21:06             ` Gordan Bobic
2011-01-06 21:39               ` Freddie Cash
2011-01-06 21:44         ` Carl Cook
2011-01-06 21:53           ` Gordan Bobic
2011-01-06 21:58           ` Freddie Cash
2011-01-06 22:26             ` Carl Cook
2011-01-06 22:29               ` Gordan Bobic
2011-01-06 23:07               ` Carl Cook
2011-01-07 16:14                 ` Hubert Kario
2011-01-06 23:15               ` Fajar A. Nugraha
2011-01-06 21:42   ` Carl Cook
2011-01-06 21:52     ` Freddie Cash
2011-01-07 16:20       ` Hubert Kario
2011-01-09 11:46         ` Alan Chandler
2011-01-09 13:54           ` Fajar A. Nugraha
2011-01-09 15:32             ` Alan Chandler
2011-01-09 17:59               ` Freddie Cash
2011-01-09 18:30                 ` Hugo Mills
2011-01-09 20:57                   ` Alan Chandler
2011-01-09 22:01                     ` Hugo Mills
2011-01-09 23:32                       ` Alan Chandler
2011-01-11 22:25                         ` Hugo Mills
2011-01-10  2:22                       ` Fajar A. Nugraha
2011-01-11 22:41                         ` Hugo Mills
2011-01-21 19:28                   ` Freddie Cash
2011-01-22 13:45                     ` Hugo Mills
2011-01-24 17:45                       ` Freddie Cash
2011-01-22 13:55                     ` Hubert Kario
2011-01-25 17:29                       ` Kaspar Schleiser
2011-01-25 17:43                         ` Hubert Kario
2011-01-25 17:59                           ` Freddie Cash [this message]
2011-01-25 18:36                             ` Hubert Kario
2011-01-10 13:14           ` Hubert Kario
2011-01-06 20:12 ` Fajar A. Nugraha
2011-01-06 21:43   ` Carl Cook
2011-01-06 21:43 ` Goffredo Baroncelli

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=AANLkTim+3+aHoX0Shc5_Fzym6_xsLAKyEA6c352nCPuD@mail.gmail.com \
    --to=fjwcash@gmail.com \
    --cc=hka@qbs.com.pl \
    --cc=kaspar@schleiser.de \
    --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;
as well as URLs for NNTP newsgroup(s).