On Wed, 31 Dec 2008 8:25:08 am Chris Mason wrote:
> This gets confusing in a hurry, but the idea is to duplicate metadata by
> default. So, if you're using the default mount options on a single
> drive and add a second drive, it should switch metadata to raid1.
Yup, that's what I inferred from y
On Wed, 31 Dec 2008 12:43:13 pm Shen Feng wrote:
> The problem still exists with -d option.
As Chris Mason wrote in response to my query on this it's a known issue that's
a consequence of different chunks potentially having different RAID levels.
The RAID level itself does appear to work - I te
On Wed, 2008-12-31 at 10:45 -0800, Andrew Morton wrote:
> On Wed, 31 Dec 2008 06:28:55 -0500 Chris Mason wrote:
>
> > Hello everyone,
>
> Hi!
>
> > I've done some testing against Linus' git tree from last night and the
> > current btrfs trees still work well.
>
> what's btrfs? I think I've he
On Wed, 31 Dec 2008 06:28:55 -0500 Chris Mason wrote:
> Hello everyone,
Hi!
> I've done some testing against Linus' git tree from last night and the
> current btrfs trees still work well.
what's btrfs? I think I've heard the name before, but I've never
seen the patches :)
--
To unsubscribe fr
> + if (block_count < 256*1024*1024) {
> + fprintf(stderr, "File system size is
> too small\n");
> + exit(1);
> + }
And please, if you could, include both the size that
Hello everyone,
I've done some testing against Linus' git tree from last night and the
current btrfs trees still work well.
There are a few bug fixes that I need to include from while I was on
vacation but I haven't made any large changes since early in December:
Btrfs details and usage informat
My test shows that at least 100M is needed for a btrfs partition.
on 12/31/2008 03:41 PM, Lee Trager wrote:
> This has been bothering me for some time. Why does btrfs need to have a
> disk greater then 256M? I could see a much smaller limit, say 16M but
> why so much? The file system itself does n
