On Oct 30, 2014, at 7:27 PM, Duncan <1i5t5.duncan@xxxxxxx> wrote:
> Chris Murphy posted on Thu, 30 Oct 2014 12:04:48 -0600 as excerpted:
>
>>> Rob, That second drive was immediately put to use elsewhere. I figured
>>> having only the metadata on that drive, it wouldn't matter. The data
>>> stayed single and wasn't part of the second drive, only the metadata
>>> was. I must not be capable of understanding why that wouldn't work.
>>
>> single profile means all devices get btrfs chunks. If you do something
>> like:
>>
>> # mkfs.btfs /dev/sda
>>
>> By default you get data profile = single, and metadata profile = DUP. If
>> you then
>>
>> # btrfs add /dev/sdb /mnt/btrfs # btrfs -mconvert=raid1 /mnt/btrfs
^device
>
> Then you (OP) go and kill that device as far as btrfs is concerned, and
> all that new data written to it in single mode is ONLY on it because it
> was written in single mode, so now it has suddenly disappeared!
>
> No WONDER that filesystem's having problems!
So what *is* possible in this case is still mount -o degraded,ro and try to extract what he can from the remaining device.
>
> Even old files, due to copy on write, would have likely been partially or
> entirely moved to the new chunks on the new device if they were updated
> during the time the filesystem was mounted writable with the new device
> there. And some desktop environments, for instance, have a habit of
> rewriting what might well be the exact same thing back to their config
> files, every time they shutdown, or sometimes as soon as they read it in
> at startup, as well. So much of your desktop config may well have been
> on that second device, even if you didn't actively change any config
> during that time.
Is hard to say. If a balance hasn't recently been done, the original device may have a good amount of free space in allocated chunks. I'm pretty sure Btrfs will write first to already allocated chunks with free space before allocating new chunks? So a bunch of stuff could actually still be on the original device - it just needs -o degraded,ro to get access to it. And if the current version of the file isn't retrievable because all or part of it's on the other drive, it'll just cause an error to occur. I think rsync and the like can be set to not fail on such errors, so anything that can be retrieved, is.
Chris Murphy--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
