On 12/09/2014 02:29 PM, Patrik Lundquist wrote:
Label: none uuid: 770fe01d-6a45-42b9-912e-e8f8b413f6a4 Total devices 1 FS bytes used 1.35TiB devid 1 size 2.73TiB used 1.36TiB path /dev/sdc1Data, single: total=1.35TiB, used=1.35TiB System, single: total=32.00MiB, used=112.00KiB Metadata, single: total=3.00GiB, used=1.55GiB GlobalReserve, single: total=512.00MiB, used=0.00B
Are you trying to convert a filesystem on a single device/partition to RAID 1?
I don't think thats legal. Whithout a second slice to distribute the copies of the data onto there is no raiding to be done.
Add the second device with btrfs device add, and _then_ use balance to redistribute and copy the data to the second device.
ASIDE: I, personally, think that a single device RAID1 should be legal. I also think that it should be possible to tell the system that you want N copies if you have N-or-more slices onto which they would spread. These would match my expectations from mdadm and several hardware and appliance RAID solutions. But my opinions in the matter do _not_ match the BTRFS code base. RAID1 means exactly two devices (for any given piece of information) [though I don't know whether it always has to be the _same_ two devices for two different pieces of information.]
So yea, if that is what you are trying to do, the inability to find a second drive on which to allocate the peer-block(s) for an extent would produce interesting errors. I cant say for sure that this is the exact genesis of your issue, but I've read here in other threads a number of comments that would translate as "trying to set RAID1 with on a one-slice file system will be full of fail".
-- 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
