On Thu, 2014-01-09 at 12:41 +0000, 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.
I'm frustrated too that I haven't pushed this out yet. I've been trying different methods to keep the performance up and in the end tried to do pile on too many other features in the patches. So, I'm breaking it up a bit and reworking things for faster release. -chris -- 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
