I wouldn't use dd.
I would use recover to get the data if at all possible, then you can
experiment with try to fix the degraded condition live. If you have
any chance of getting data from the pool, you reduce that chance every
time you make a change.
If btrfs did the balance like you said, it wouldn't be raid5. What
you just described is raid4 where only one drive holds parity data. I
can't say that I actually know for a fact that btrfs doesn't do this,
but I'd be shocked and some dev would need to eat their underware if
the balance job didn't distribute the parity also.
On Wed, Jul 8, 2015 at 1:56 PM, Hendrik Friedel <hend...@friedels.name> wrote:
> Hello,
>
> yes, I will check the cables, thanks for the hint.
> Before trying to recover the data, I would like to save the status quo. I
> have two new drives? Is it advisable to dd-copy the data on the new drives
> and then to try to recover?
>
> I am asking, because I suppose that dd will also copy the UUID, which might
> confuse BTRFS (two drives with same UUID attached)?
>
> And then I have a technical question on btrfs balance when converting to
> raid5 (from raid1): does the balance create the parity information on the
> newly-added (empty) drive, so that the data on the two original disks is not
> touched at all?
>
> Regards,
> Hendrik
>
>
>
> On 07.07.2015 15:14, Donald Pearson wrote:
>>
>> That's what it looks like. You may want to try reseating cables, etc.
>>
>> Instead of mounting and file copy, btrfs restore might be worth a shot
>> to recover what you can.
>>
>> On Tue, Jul 7, 2015 at 12:42 AM, Hendrik Friedel <hend...@friedels.name>
>> wrote:
>>>
>>> Hello,
>>>
>>> while mounting works with the recovery option, the system locks after
>>> reading.
>>> dmesg shows:
>>> [ 684.258246] ata6.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
>>> [ 684.258249] ata6.00: irq_stat 0x40000001
>>> [ 684.258252] ata6.00: failed command: DATA SET MANAGEMENT
>>> [ 684.258255] ata6.00: cmd 06/01:01:00:00:00/00:00:00:00:00/a0 tag 26
>>> dma
>>> 512 out
>>> [ 684.258255] res 51/04:01:01:00:00/00:00:00:00:00/a0 Emask 0x1
>>> (device error)
>>> [ 684.258256] ata6.00: status: { DRDY ERR }
>>> [ 684.258258] ata6.00: error: { ABRT }
>>> [ 684.258266] sd 5:0:0:0: [sdd] tag#26 FAILED Result: hostbyte=DID_OK
>>> driverbyte=DRIVER_SENSE
>>> [ 684.258268] sd 5:0:0:0: [sdd] tag#26 Sense Key : Illegal Request
>>> [current] [descriptor]
>>> [ 684.258270] sd 5:0:0:0: [sdd] tag#26 Add. Sense: Unaligned write
>>> command
>>> [ 684.258272] sd 5:0:0:0: [sdd] tag#26 CDB: Write same(16) 93 08 00 00
>>> 00
>>> 00 00 01 d3 80 00 00 00 80 00 00
>>>
>>>
>>> So, also this drive is failing?!
>>>
>>> Regards,
>>> Hendrik
>>>
>>>
>>> On 07.07.2015 00:59, Donald Pearson wrote:
>>>>
>>>>
>>>> Anything in dmesg?
>>>>
>>>> On Mon, Jul 6, 2015 at 5:07 PM, hend...@friedels.name
>>>> <hend...@friedels.name> wrote:
>>>>>
>>>>>
>>>>> Hallo,
>>>>>
>>>>> It seems, that mounting works, but the System locks completely soon
>>>>> after
>>>>> I
>>>>> backing up.
>>>>>
>>>>>
>>>>> Greetings,
>>>>>
>>>>> Hendrik
>>>>>
>>>>>
>>>>> ------ Originalnachricht------
>>>>>
>>>>> Von: Donald Pearson
>>>>>
>>>>> Datum: Mo., 6. Juli 2015 23:49
>>>>>
>>>>> An: Hendrik Friedel;
>>>>>
>>>>> Cc: Omar Sandoval;Hugo Mills;Btrfs BTRFS;
>>>>>
>>>>> Betreff:Re: size 2.73TiB used 240.97GiB after balance
>>>>>
>>>>>
>>>>> If you can mount it RO, first thing to do is back up any data that
>>>>> youcare
>>>>> about.According to the bug that Omar posted you should not try a
>>>>> devicereplace and you should not try a scrub with a missing device.You
>>>>> may
>>>>> be able to just do a device delete missing, then separately doa device
>>>>> add
>>>>> of a new drive, or rebalance back in to raid1.On Mon, Jul 6, 2015 at
>>>>> 4:12
>>>>> PM, Hendrik Friedel wrote:> Hello,>> oh dear, I fear I am in trouble:>
>>>>> recovery-mounted, I tried to save some data, but the system hung.> So I
>>>>> re-booted and sdc is now physically disconnected.>> Label: none uuid:
>>>>> b4a6cce6-dc9c-4a13-80a4-ed6bc5b40bb8> Total devices 3 FS bytes
>>>>> used
>>>>> 4.67TiB> devid 1 size 2.73TiB used 2.67TiB path /dev/sdc>
>>>>> devid 2 size 2.73TiB used 2.67TiB path /dev/sdb> *** Some
>>>>> devices
>>>>> missing>> I try to mount the rest again:> mount -o recovery,ro /dev/sdb
>>>>> /mnt/__Complete_Disk> mount: wrong fs type, bad option, bad superblock
>>>>> on
>>>>> /dev/sdb,> missing codepage or helper program, or other error>
>>>>> In some cases useful info is found in syslog - try> dmesg | tail
>>>>> or
>>>>> so>> root@homeserver:~# dmesg | tail> [ 447.059275] BTRFS info (device
>>>>> sdc): enabling auto recovery> [ 447.059280] BTRFS info (device sdc):
>>>>> disk
>>>>> space caching is enabled> [ 447.086844] BTRFS: failed to read chunk
>>>>> tree
>>>>> on
>>>>> sdc> [ 447.110588] BTRFS: open_ctree failed> [ 474.496778] BTRFS info
>>>>> (device sdc): enabling auto recovery> [ 474.496781] BTRFS info (device
>>>>> sdc): disk space caching is enabled> [ 474.519005] BTRFS: failed to
>>>>> read
>>>>> chunk tree on sdc> [ 474.540627] BTRFS: open_ctree failed>>> mount -o
>>>>> degraded,ro /dev/sdb /mnt/__Complete_Disk> Does work now though.>> So,
>>>>> how
>>>>> can I remove the reference to the failed disk and check the data for>
>>>>> consistency (scrub I suppose, but is it safe?)?>> Regards,>
>>>>> Hendrik>>>>>
>>>>> On
>>>>> 06.07.2015 22:52, Omar Sandoval wrote:>>>> On 07/06/2015 01:01 PM,
>>>>> Donald
>>>>> Pearson wrote:>>>>>> Based on my experience Hugo's advice is critical,
>>>>> get
>>>>> the bad drive>>> out of the pool when in raid56 and do not try to
>>>>> replace
>>>>> or
>>>>> delete it>>> while it's still attached and recognized.>>>>>> If you add
>>>>> a
>>>>> new device, mount degraded and rebalance. If you don't,>>> mount
>>>>> degraded
>>>>> then device delete missing.>>>>>>> Watch out, replacing a missing
>>>>> device
>>>>> in
>>>>> RAID 5/6 currently doesn't work>> and will cause a kernel BUG(). See my
>>>>> patch series here:>>
>>>>> http://www.spinics.net/lists/linux-btrfs/msg44874.html>>>>> --> Hendrik
>>>>> Friedel> Auf dem Brink 12> 28844 Weyhe> Tel. 04203 8394854> Mobil 0178
>>>>> 1874363>>> ---> Diese E-Mail wurde von Avast Antivirus-Software auf
>>>>> Viren
>>>>> geprüft.> https://www.avast.com/antivirus>
>>>
>>>
>>>
>>>
>>> --
>>> Hendrik Friedel
>>> Auf dem Brink 12
>>> 28844 Weyhe
>>> Tel. 04203 8394854
>>> Mobil 0178 1874363
>>>
>>> ---
>>> Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft.
>>> https://www.avast.com/antivirus
>>>
>
>
> --
> Hendrik Friedel
> Auf dem Brink 12
> 28844 Weyhe
> Tel. 04203 8394854
> Mobil 0178 1874363
>
> ---
> Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft.
> https://www.avast.com/antivirus
>
--
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
