Btrfs devel - Jan 2012 - newbie problems (difficulty with mkfs.btrfs and learning how to navigate trees

Hi everyone, I''m trying to learn about btrfs and the various trees and
data
structures.  To that end I have been trying to create a small RAID 1
filesystem (with 2 10MB devices), and it appears mkfs.btrfs does not like
this. (output follows

  # ./mkfs.btrfs -d raid1 -m raid1 -b 10485760 /dev/ubdc /dev/ubdb
  SMALL VOLUME: forcing mixed metadata/data groups

  WARNING! - Btrfs Btrfs v0.19 IS EXPERIMENTAL
  WARNING! - see http://btrfs.wiki.kernel.org before using

  Created a data/metadata chunk of size 1048576
  adding device /dev/ubdb id 2
  mkfs.btrfs: mkfs.c:221: create_one_raid_group: Assertion `!(ret)''
failed.
  Aborted

However if I don''t set the raid1 options, I can create a 20 MB RAID0
filesystem, or I can also create a 10 MB filesystem on one disk
without any errors.  Large disk devices also seem to work as RAID1 or
RAID0)

I''m really just trying to start to dig in and understand the code, but
I
figured a small filesystem would be easier to walk. I might just mess
with a single disk for now, but I would appreciate any advice.

Thanks,

Rohit
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs"
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Rohit Mehta posted on Sun, 29 Jan 2012 22:06:59 -0500 as excerpted:
> Hi everyone, I''m trying to learn about btrfs and the various trees
and
> data structures.  To that end I have been trying to create a small RAID
> 1 filesystem (with 2 10MB devices), and it appears mkfs.btrfs does not
> like this. (output follows
> 
>   # ./mkfs.btrfs -d raid1 -m raid1 -b 10485760 /dev/ubdc /dev/ubdb SMALL
>   VOLUME: forcing mixed metadata/data groups
> 
>   WARNING! - Btrfs Btrfs v0.19 IS EXPERIMENTAL WARNING! - see
>   http://btrfs.wiki.kernel.org before using
> 
>   Created a data/metadata chunk of size 1048576 adding device /dev/ubdb
>   id 2 mkfs.btrfs: mkfs.c:221: create_one_raid_group: Assertion
`!(ret)''
>   failed.
>   Aborted
> 
> However if I don''t set the raid1 options, I can create a 20 MB
RAID0
> filesystem, or I can also create a 10 MB filesystem on one disk without
> any errors.  Large disk devices also seem to work as RAID1 or RAID0)
> 
> I''m really just trying to start to dig in and understand the code,
but I
> figured a small filesystem would be easier to walk. I might just mess
> with a single disk for now, but I would appreciate any advice.
Hi.  FWIW, I''m only researching btrfs at this point in preparation for 
installing, so while I have the kernel options active and tools 
installed, that''s as far as I''ve gotten on the actually doing
it side.
The below is thus based on recent posts here, the tools manpages, and the 
wiki, at:

https://btrfs.wiki.kernel.org/


First, a general point.  You don''t mention what kernel or tools sources
you are using.  btrfs is still under rapid development and every new 
kernel version brings bugfixes and tweaks, so you really want at least 
the latest stable kernel available (3.2.something at this point), if not 
the development kernels (3.3-rcs at this point or live-git).  Similarly 
with the tools. The 0.19 release was in 2009 and simply isn''t current.
Users of this experimental filesystem really should be running a recently 
built live-git version.  There''s actually two trees available, the 
official kernel.org tree, and the "integration tree", which tracks 
patches seen on the list.  See the wiki for more.

Second, the mixed-chunk (data/metadata) code is quite new, and not yet 
well tested.  This doubles-down on the point above -- you WILL want the 
latest code if you''re doing mixed-chunk, which you will be with small 
fileystems, see the next point.

Third, "small" is relative!

On the wiki there''s a pre-mixed-chunk example of a "small"
btrfs
filesystem of 4 GB!  I''m on record here as grumbling that perhaps it 
makes me old, but I wouldn''t call anything measured in the gigabytes 
particularly "small", even if in practical terms it is on
today''s disks!
Another spot recommends filesystems no smaller than a gigabyte, noting 
that (again, pre-mixed-chunk), even with that, one should expect to lose 
a quarter of it to metadata, given chunk limitations.

Mixed-chunk does have the down side of more fragmentation, however, so 
it''s recommended for filesystems of 1 GB or smaller to better utilize
the
space, but not for > 1 GB.

Obviously, with a 10 MB filesystem you''re definitely testing the lower 
limits of a filesystem that calls even a four-gig fileystem "small"!  
Combine that with the newness of the mixed-chunk code and the fact that 
you might be running (relatively) older code (with "older" in this
case
potentially meaning live-git kernel and integration-tree userspace more 
than, say, a week old, especially given the newness of mixed-chunk mode 
itself).

It''s quite likely that mixed-mode simply won''t yet work on
that tiny a
filesystem created with raid1 mode data, but for sure I''d try it with
the
latest code, in case the problem is now fixed.

So, I''d say try it with something larger, probably 1/8 gig to 1/4 gig
at
least.  Or if that''s not convenient at present, run as you mentioned, 
either raid0 mode or one device, no-raid, for now.


Meanwhile, my interest involves raid1 mode on (relatively) small devices, 
tho not 10 MB small, more like 128 MB small, as well.  As such, you may 
wish to check my posts for the last few days.  I''ve responded to
several
questions such as yours based on the wiki info, but also started a thread 
with a number of related questions (btrfs-raid questions I couldn''t
find
an answer to on the wiki, posted last Thursday).

Of particular interest there, we were debating even a 128 MB btrfs image 
(raid1), in my case for a separate /boot partition.  The recommendation 
was to make it bigger, quarter or half gig (which I could do as I have a 
bit of free space on the drives I''ll be using, unused with the current 
layout), or for such a small and special-purpose filesystem, to use 
something more traditional, probably either the reiserfs I''m using now
or
ext2/3/4.

(If you just joined the list and don''t know where to find an archive to
look up older posts, I''m using gmane.org, here.  I use the newsgroup 
interface for both reading and posting, but they also have a web 
interface, if you prefer.)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs"
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On Mon, Jan 30, 2012 at 12:56 AM, Duncan <1i5t5.duncan@cox.net> wrote:
> First, a general point.  You don''t mention what kernel or tools
sources
> you are using.
My apologies! I was using the 3.2.2 kernel and the unstable btrfs
tools from the Integration repository as of last night
( http://git.darksatanic.net/repo/btrfs-progs-unstable.git )  Although
I did try with certain other permutations of kernels and versions of
btrfs-progs.

I''m only playing with BTRFS in UML, trying to understand how it works
at this point.
> It''s quite likely that mixed-mode simply won''t yet work
on that tiny a
> filesystem created with raid1 mode data, but for sure I''d try it
with the
> latest code, in case the problem is now fixed.
>
> So, I''d say try it with something larger, probably 1/8 gig to 1/4
gig at
> least.  Or if that''s not convenient at present, run as you
mentioned,
> either raid0 mode or one device, no-raid, for now.
Thanks, it does seem to work on larger filesystems.  I''ll work with
500 MB virtual disks.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs"
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Rohit Mehta posted on Mon, 30 Jan 2012 11:38:51 -0500 as excerpted:
> Thanks, it does seem to work on larger filesystems.  I''ll work
with 500
> MB virtual disks.
FWIW I''d suggest 512 MiB, just because btrfs seems to like powers of
two
as opposed to powers of 10.  That might be what you meant anyway, but 
it''s not what you posted.  =:^/

Talking about which, if you want to try 500 vs 512 vs 520 (or 512 plus 
whatever the system usage size turns out to be for such a volume, I 
assumed 8 MiB here), I''d be quite interested in comparative results. 
It
may be that getting it exactly right means a far more efficient layout, 
less space waste and faster access, or that it really doesn''t matter
that
much.  I don''t know, which is why the results of such a test would be
so
interesting. =:^)

Of course on real disks as opposed to virtual, speed would depend on the 
disk alignment (512 byte vs 4KiB physical sectors and alignment to it, 
for spinning media, larger erase chunks, up to 1 or 4 MiB, likely on ssd), 
etc, but physical disk layout shouldn''t directly affect btrfs''
chunk-size
and space utilization efficiency.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs"
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html