Re: filesystem seeding ... BUGs on .38, .39, loopback, real devices, tmp branch ... everything

2011-06-02 Thread Geoff Ritter
On Thu, 2011-06-02 at 04:20 -0500, C Anthony Risinger wrote:
 
 i tried with loop devices at first, then real devices -- this is all
 under KVM/QEMU, and with FSs that are/will be smaller than 1G.

I have tried the seed option as well.  I was able to successfully mount
the read write partition after setting up the seed.  However, both had
to be independent partitions on a real device.

During testing, both .38 and .39rc could NOT create a seed if one or
both partitions were encrypted.  I believe encrypted partitions also
work with a loop device for the unlocked version you write too.  The
response I got after a few days is as follows:

 Chris Mason chris.ma...@oracle.com
 cwillu cwi...@cwillu.com
 date  Thu, May 5, 2011 at 4:42 PM
 Ok, looks like I busted the seed support
 when I fixed up some of the chunk
 allocations.  I'll reproduce this and
 work out a fix.

I just assumed it would take a while to fix so I haven't tried again
since.  If the root of the problem appears to be loop devices, you might
want to report that.  Err I guess you did.  To me, this doesn't explain
why it wouldn't work in a Virtual Machine.  I would have thought the VM
would treat it as a real device.



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


Re: filesystem seeding ... BUGs on .38, .39, loopback, real devices, tmp branch ... everything

2011-06-02 Thread C Anthony Risinger
On Thu, Jun 2, 2011 at 6:40 AM, Geoff Ritter geoff.rit...@gmail.com wrote:
 On Thu, 2011-06-02 at 04:20 -0500, C Anthony Risinger wrote:

 i tried with loop devices at first, then real devices -- this is all
 under KVM/QEMU, and with FSs that are/will be smaller than 1G.

 I have tried the seed option as well.  I was able to successfully mount
 the read write partition after setting up the seed.  However, both had
 to be independent partitions on a real device.

 During testing, both .38 and .39rc could NOT create a seed if one or
 both partitions were encrypted.  I believe encrypted partitions also
 work with a loop device for the unlocked version you write too.  The
 response I got after a few days is as follows:

 Chris Mason chris.ma...@oracle.com
 cwillu cwi...@cwillu.com
 date  Thu, May 5, 2011 at 4:42 PM
 Ok, looks like I busted the seed support
 when I fixed up some of the chunk
 allocations.  I'll reproduce this and
 work out a fix.

 I just assumed it would take a while to fix so I haven't tried again
 since.  If the root of the problem appears to be loop devices, you might
 want to report that.  Err I guess you did.  To me, this doesn't explain
 why it wouldn't work in a Virtual Machine.  I would have thought the VM
 would treat it as a real device.

yeah ... i wasn't sure if this was the same exact problem you had or
what, i can't find much info at all about anyone using seed support.

i tried loop devices on my real machine too (.38), and because of
continuous oops/locks i moved to a VM so i didn't hose my system.
however, when i tried with real devices in the VM, these were not
loopbacks, they were just regular raw files used as backing for QEMU
(though i don't know if it internally uses loopback) ... they were
exposed as virtio devices /dev/vdb and /dev/vdc.  i got the exact same
results using those devices, using btrfs-vol instead of btrfs, and a
whole slew of other trial and error that all led to the same issue.

the 10 lines or so i provided earlier reproduces consistently for me
... in the end, it *seemed* to work, but still :-)

what i REALLY want though, is simply more information on how seeding
works and should be used ... the wiki et al seem to imply that i can
reuse the seed device for MULTIPLE filesystems ... how can i do this?
i tried adding the device to an existing array but i couldnt see any
files ... can anyone shed some light on this feature?

thanks much,

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