All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Jean-Philippe Robichaud" <jean.philippe.robichaud@gmail.com>
To: linux-btrfs@vger.kernel.org
Subject: Re: unexpected raid1 behavior?
Date: Fri, 27 Nov 2009 17:36:22 -0500	[thread overview]
Message-ID: <200911271736.22930.jean.philippe.robichaud@gmail.com> (raw)
In-Reply-To: <20091127210442.GA18273@vlad.carfax.org.uk>

On Friday 27 November 2009 16:04:42 Hugo Mills wrote:
> yOn Fri, Nov 27, 2009 at 03:41:17PM -0500, Jean-Philippe Robichaud wrote:
> > Now I have 2 partitions (on 2 different sata disks) that are free for me
> > to play with, each about 375 gb in size.  I wanted to create a "raid1"
> > volume using these two partitions, so I did:
> >
> > # mkfs.btrfs -d raid1 /dev/sda5 /dev/sdb5
> > # mount /dev/sda5 /btrfs
> >
> > and everything seems fine.
> >
> > Now what I find strange is that everything looks like a raid0 was
> > created, not a raid1:
> >
> > $ df -h /btrfs/
> >  Filesystem            Size  Used Avail Use% Mounted on
> > /dev/sda5             684G   72G  612G  11% /btrfs
> >
> > What am I doing (or understanding) wrong?
> 
>    It's effectively showing you the number of unallocated blocks, so
> (with a RAID-1, single-redundancy filesystem), files will appear to
> take twice as much of your free space as you think they should: write
> a 2GiB file to that filesystem, and free space will drop by 4GiB.
> 
>    I think that the reasoning behind this is that if you're using
> per-object mirroring/striping, it's impossible to give a precise count
> of the free space remaining on the volume in any meaningful way: write
> a 1GiB striped file, and you'll take 1GiB of space; write the same
> file mirrored, and you'll take 2GiB of space.
> 
>    Hugo.
> 
Thanks for your input Hugo, but somehow it looks like something different is 
happening:

du toto
1088 toto
$ df .
/dev/sda5            716579256  75455900 641123356  11% /btrfs
$ cp toto toto2 
$ btrfsctl -c .
$ df .
/dev/sda5            716579256  75456992 641122264  11% /btrfs

So 1092 block were 'consumed', we're far from the +2000 I would have 
expected...

Is there a place in /sys or /proc where I could perhaps get 'stats' about the 
btrfs volume?


  reply	other threads:[~2009-11-27 22:36 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-27 20:41 unexpected raid1 behavior? Jean-Philippe Robichaud
2009-11-27 21:04 ` Hugo Mills
2009-11-27 22:36   ` Jean-Philippe Robichaud [this message]
2009-11-29 12:42     ` Sander
2009-11-29 21:28       ` Jean-Philippe Robichaud
2009-11-30 16:20         ` jean-philippe robichaud

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=200911271736.22930.jean.philippe.robichaud@gmail.com \
    --to=jean.philippe.robichaud@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.