From: Josef Bacik <jbacik@fusionio.com>
To: David Sterba <dave@jikos.cz>
Cc: "cbay@alwaysdata.com" <cbay@alwaysdata.com>,
"linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org>,
Josef Bacik <JBacik@fusionio.com>
Subject: Re: mkfs devices ordering relevant with devices of different sizes?
Date: Fri, 27 Jul 2012 08:05:29 -0400 [thread overview]
Message-ID: <20120727120529.GA13442@localhost.localdomain> (raw)
In-Reply-To: <20120726210959.GK17430@twin.jikos.cz>
On Thu, Jul 26, 2012 at 03:09:59PM -0600, David Sterba wrote:
> On Wed, Jul 25, 2012 at 03:26:20PM +0200, Cyril B. wrote:
> > When creating a filesystem with devices of different sizes, the resulting
> > filesystem total size depends on the device order specified to mkfs. When
> > the smaller device is specified first, the second (larger) device is seen as
> > the same size as the first. This doesn't occur when the order is reversed.
> >
> > It's confusing. Is this expected? I'm using the latest btrfs-progs and Linux
> > 3.5.
>
> Confusing it is, caused by this commit
>
> Author: Josef Bacik <josef@redhat.com>
> AuthorDate: Wed Mar 28 14:20:52 2012 -0400
> Commit: Chris Mason <chris.mason@fusionio.com>
> CommitDate: Tue Jul 3 16:27:46 2012 -0400
>
> btrfs-progs: enforce block count on all devices in mkfs
>
> I had a test that creates a 7gig raid1 device but it was ending up wonky
> because the second device that gets added is the full size of the disk
> instead of the limited size. So enforce the limited size on all disks
> passed in at mkfs time, otherwise our threshold calculations end up wonky
> when doing chunk allocations. Thanks,
Ooops, that's definitely not what I intended, I will fix that up right away,
sorry about that. Thanks,
Josef
prev parent reply other threads:[~2012-07-27 12:05 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-25 13:26 mkfs devices ordering relevant with devices of different sizes? Cyril B.
2012-07-26 21:09 ` David Sterba
2012-07-27 12:05 ` Josef Bacik [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=20120727120529.GA13442@localhost.localdomain \
--to=jbacik@fusionio.com \
--cc=cbay@alwaysdata.com \
--cc=dave@jikos.cz \
--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.