Re: Question: raid1 behaviour on failure

[Liu Bo <bo.li.liu@oracle.com>]

On Thu, Apr 21, 2016 at 01:43:56PM +0800, Qu Wenruo wrote:
> 
> 
> Matthias Bodenbinder wrote on 2016/04/21 07:22 +0200:
> >Am 20.04.2016 um 09:25 schrieb Qu Wenruo:
> >
> >>
> >>Unfortunately, this is the designed behavior.
> >>
> >>The fs is rw just because it doesn't hit any critical problem.
> >>
> >>If you try to touch a file and then sync the fs, btrfs will become RO immediately.
> >>
> >....
> >
> >>Btrfs fails to read space cache, nor make a new dir.
> >>
> >>The failure on cow_block in mkdir is ciritical, and btrfs become RO.
> >>
> >>All expected behavior so far.
> >>
> >>You may try use degraded mount option, but AFAIK it may not handle case like yours.
> >
> >This really scares me. "Expected bevahour"?
> >So you are saying: If one of the drives in the raid1 is going dead without noticing btrfs, the redundancy is lost.
> >
> >Lets say, the power unit of a disc is going dead. This disc will disappear from the raid1 pretty much as suddenly as in my test case here. No difference.
> >
> >You are saying that in this case, btrfs should exactly behave like this? If that is the case I eventually need to rethink my interpretation of redundancy.
> >
> >Matthias
> >
> 
> The "expected behavior" just means the abort transaction behavior for
> critical error is expected.
> 
> And you should know, btrfs is not doing full block level RAID1, it's doing
> RAID at chunk level.
> Which needs to consider more things than full block level RAID1, and it's
> more flex than block level raid1.
> (For example, you can use 3 devices with different sizes to do btrfs RAID1
> and get more available size than mdadm raid1)
> 
> You may think the behavior is totally insane for btrfs RAID1, but don't
> forget, btrfs can have different metdata/data profile.
> (And even more, there is already plan to support different profile for
> different subvolumes)
> 
> In case your metadata is RAID1, your data can still be RAID0, and in that
> case a missing devices can still cause huge problem.

>From an user's point of view, what you're saying is more an excuse and
kind of irrelavant.  Stop doing that please, try to fix the insane behavior instead.

Thanks,

-liubo

> 
> There are already unmerged patches which will partly do the mdadm level
> behavior, like automatically change to degraded mode without making the fs
> RO.
> 
> The original patchset:
> http://comments.gmane.org/gmane.comp.file-systems.btrfs/48335
> 
> Or the latest patchset inside Anand Jain's auto-replace patchset:
> http://thread.gmane.org/gmane.comp.file-systems.btrfs/55446
> 
> Thanks,
> Qu
> >
> >
> >--
> >To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> >the body of a message to majordomo@vger.kernel.org
> >More majordomo info at  http://vger.kernel.org/majordomo-info.html
> >
> >
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html