linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Hugo Mills <hugo@carfax.org.uk>
To: Tim Eggleston <lists@timeggleston.co.uk>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: RAID10 total capacity incorrect
Date: Sun, 2 Jun 2013 18:41:18 +0100	[thread overview]
Message-ID: <20130602174118.GH20133@carfax.org.uk> (raw)
In-Reply-To: <4cd17d2ff5a252261c4ab2f3800207b5@mail.39.gs>

[-- Attachment #1: Type: text/plain, Size: 1496 bytes --]

On Sun, Jun 02, 2013 at 05:52:38PM +0100, Tim Eggleston wrote:
> Hi Hugo,
> 
> Thanks for your reply, good to know it's not an error as such (just
> me being an idiot!).
> 
> >Additional space will be allocated from the available unallocated
> >space as the FS needs it.
> 
> So I guess my question becomes, how much of that available
> unallocated space do I have? Instinctively the btrfs df output feels
> like it's missing an equivalent to the "size" column from vanilla
> df.

   Look at btrfs fi show -- you have "size" and "used" there, so the
difference there will give you the unallocated space.

> Is there a method of getting this in a RAID situation? I understand
> that btrfs RAID is more complicated than md RAID, so it's ok if the
> answer at this point is "no"...

   Not in any obvious (and non-surprising) way. Basically, any way you
could work it out is going to give someone a surprise because they
were thinking of it some other way around. The problem is that until
the space is allocated, the FS can't know how that space needs to be
allocated (to data/metadata, or with what replication type and hence
overheads), so we can't necessarily give a reliable estimate.

   Hugo.

-- 
=== Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk ===
  PGP key: 65E74AC0 from wwwkeys.eu.pgp.net or http://www.carfax.org.uk
         --- If you're not part of the solution, you're part ---         
                           of the precipiate.                            

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

  reply	other threads:[~2013-06-02 17:41 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-06-02 16:17 RAID10 total capacity incorrect Tim Eggleston
2013-06-02 16:30 ` Hugo Mills
2013-06-02 16:52   ` Tim Eggleston
2013-06-02 17:41     ` Hugo Mills [this message]
2013-06-02 16:52 ` Chris Murphy
2013-06-02 17:43   ` Hugo Mills
2013-06-03  5:26     ` Duncan
2013-06-03  8:02       ` Tim Eggleston
2013-06-04  5:30         ` 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=20130602174118.GH20133@carfax.org.uk \
    --to=hugo@carfax.org.uk \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=lists@timeggleston.co.uk \
    /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).