On 2014-01-09 07:41, Duncan wrote:
> Hugo Mills posted on Thu, 09 Jan 2014 10:42:47 +0000 as excerpted:
>
>> On Thu, Jan 09, 2014 at 11:26:26AM +0100, Clemens Eisserer wrote:
>>> Hi,
>>>
>>> I am running write-intensive (well sort of, one write every 10s)
>>> workloads on cheap flash media which proved to be horribly unreliable.
>>> A 32GB microSDHC card reported bad blocks after 4 days, while a usb pen
>>> drive returns bogus data without any warning at all.
>>>
>>> So I wonder, how would btrfs behave in raid1 on two such devices? Would
>>> it simply mark bad blocks as "bad" and continue to be operational, or
>>> will it bail out when some block can not be read/written anymore on one
>>> of the two devices?
>>
>> If a block is read and fails its checksum, then the other copy (in
>> RAID-1) is checked and used if it's good. The bad copy is rewritten to
>> use the good data.
>
> This is why I'm (semi-impatiently, but not being a coder, I have little
> choice, and I do see advances happening) so looking forward to the
> planned N-way-mirroring, aka true-raid-1, feature, as opposed to btrfs'
> current 2-way-only mirroring. Having checksumming is good, and a second
> copy in case one fails the checksum is nice, but what if they BOTH do?
> I'd love to have the choice of (at least) three-way-mirroring, as for me
> that seems the best practical hassle/cost vs. risk balance I could get,
> but it's not yet possible. =:^(
>
> For (at least) year now, the roadmap has had N-way-mirroring on the list
> for after raid5/6 as they want to build on its features, but (like much
> of the btrfs work) raid5/6 took about three kernels longer to introduce
> than originally thought, and even when introduced, the raid5/6 feature
> lacked some critical parts (like scrub) and wasn't considered real-world
> usable as integrity over a crash and/or device failure, the primary
> feature of raid5/6, couldn't be assured. That itself was about three
> kernels ago now, and the raid5/6 functionality remains partial -- it
> writes the data and parities as it should, but scrub and recovery remain
> only partially coded, so it looks like that'll /still/ be a few more
> kernels before that's fully implemented and most bugs worked out, with
> very likely a similar story to play out for N-way-mirroring after that,
> thus placing it late this year for introduction and early next for
> actually usable stability.
>
> But it remains on the roadmap and btrfs should have it... eventually.
> Meanwhile, I keep telling myself that this is filesystem code which a LOT
> of folks including me stake the survival of their data on, and I along
> with all the others definitely prefer it done CORRECTLY, even if it takes
> TEN years longer than intended, than have it sloppily and unreliably
> implemented sooner.
>
> But it's still hard to wait, when sometimes I begin to think of it like
> that carrot suspended in front of the donkey, never to actually be
> reached. Except... I *DO* see changes, and after originally taking off
> for a few months after my original btrfs investigation, finding it
> unusable in its then-current state, upon coming back about 5 months
> later, actual usability and stability on current features had improved to
> the point that I'm actually using it now, so there's certainly progress
> being made, and the fact that I'm actually using it now attests to that
> progress *NOT* being a simple illusion. So it'll come, even if it /does/
> sometimes seem it's Duke-Nukem-Forever.
>
Just a thought, you might consider running btrfs on top of LVM in the
interim, it isn't quite as efficient as btrfs by itself, but it does
allow N-way mirroring (and the efficiency is much better now that they
have switched to RAID1 as the default mirroring backend)
--
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
