linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Chandan Rajendra <chandan@linux.vnet.ibm.com>
To: "Theodore Ts'o" <tytso@mit.edu>
Cc: fstests@vger.kernel.org, linux-btrfs@vger.kernel.org,
	linux-fsdevel@vger.kernel.org, chandan@mykolab.com
Subject: Re: [PATCH] generic/224: Increase filesystem instance size to 1.5 GiB
Date: Tue, 01 Sep 2015 05:49:14 +0530	[thread overview]
Message-ID: <160121092.hSkPuGCNnN@localhost.localdomain> (raw)
In-Reply-To: <20150831181127.GB7642@thunk.org>

On Monday 31 Aug 2015 14:11:27 Theodore Ts'o wrote:
> On Sun, Aug 30, 2015 at 08:16:21PM +0530, Chandan Rajendra wrote:
> > For small filesystem instances (i.e. size <= 1 GiB), mkfs.btrfs fails when
> > "data block size" does not match with the "metadata block size" specified
> > on the mkfs.btrfs command line. This commit increases the size of
> > filesystem instance created so that the test can be executed on
> > subpagesize-blocksize Btrfs instances which have different values for
> > data and metadata blocksizes.
> Stupid question --- why isn't this considered a bug in mkfs.btrfs?
> Does btrfs simply not support file systems <= 1 GB?  So if someone has
> a 1GB USB disk or SD card, what's the official advice from the btrfs
> developers?  Use xfs or ext4?
> 
Ted, Btrfs does indeed support filesystem instances <= 1GiB. When creating
such instances, mixed block groups are created i.e. These block groups hold
both data and metadata. Hence the requirement of having matching "data block
size" and "metadata block size" for filesystems <= 1 GiB.

mkfs.btrfs when invoked on small filesystems by "not" specifying any block
sizes (i.e. mkfs.btrfs -f /dev/sda1) will automatically create filesystem
instance with "data block size" == "metadata block size". However in the
subpagesize-blocksize scenario, we need to specify both data and metadata
block size on the command line (For e.g. mkfs.btrfs -f -s 4096 -n 16384
/dev/sda1). In this case, Since the user is forcing the block sizes and it is
impossible to have mixed block groups with differing data and metadata block
sizes, mkfs.btrfs will fail.

-- 
chandan

  parent reply	other threads:[~2015-09-01  0:19 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-30 14:46 [PATCH] generic/224: Increase filesystem instance size to 1.5 GiB Chandan Rajendra
2015-08-31 18:11 ` Theodore Ts'o
2015-08-31 19:19   ` Austin S Hemmelgarn
2015-08-31 21:09     ` Theodore Ts'o
2015-09-01  0:19   ` Chandan Rajendra [this message]
2015-09-01  0:38     ` Chandan Rajendra
2015-09-01  2:15     ` Theodore Ts'o
2015-09-01  2:33       ` Chandan Rajendra
2015-09-11  1:38         ` Qu Wenruo
2015-09-22  5:18           ` Chandan Rajendra

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=160121092.hSkPuGCNnN@localhost.localdomain \
    --to=chandan@linux.vnet.ibm.com \
    --cc=chandan@mykolab.com \
    --cc=fstests@vger.kernel.org \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=tytso@mit.edu \
    /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).