On Tue, 02 Mar 2010 19:14:25 +0100 Asdo <asdo@xxxxxxxxxxxxx> wrote: > Luca Berra wrote: > >>> > >>> I will try to explain better, > >>> the problem is not related to the confusion between B or B' > >>> > >>> the problem is that on one disk we have B' _without_ C. > >>> > >> You're demanding full atomic commits; this is precisely what journals > >> and /barriers/ are for. > >> > >> Are you are bypassing them in a quest for performance and paying for > >> it on crashes? > >> Or is this a hardware bug? > >> Or is it some glitch in the block device layering leading to barrier > >> requests not being honored? > > I just asked for confirmation that with /barriers/ the scenario above > > would not happen. > > > > I think so, that it would not happen: the filesystem would stay > consistent. (while the mismatches could still happen) > > The problem is that the barriers were introduced in all md raids in the > 2.6.33 (just released), and also I have read XFS has a major performance > drop with barriers activated. People will be tempted to disable > barriers. AFAIR the performance drop was visible with 1 disk alone, > imagine now with RAID. And I expect similar performance drops with other > filesystems, correct me if I am wrong. The barrier support added in 2.6.33 was for striped md arrays. RAID1, which is not striped, has had barrier support since about 2.6.16, as it is much easier to implement. NeilBrown > > Now it would be interesting to understand why the mismatches don't > happen when LVM is above MD-raid!? > The mechanisms presented up to now on this ML for mismatches don't > explain why on LVM the same issue doesn't show up. I think. > So you might want to use raid-1 and raid-10 under LVM, just in case.... > -- > To unsubscribe from this list: send the line "unsubscribe linux-raid" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
