Messages in this thread | | | Date | Sat, 16 Aug 2003 16:52:45 -0700 | From | Mike Fedyk <> | Subject | Re: data corruption using raid0+lvm2+jfs with 2.6.0-test3 |
| |
On Sat, Aug 16, 2003 at 06:00:21PM +1000, Neil Brown wrote: > On Friday August 15, mfedyk@matchmail.com wrote: > > On Wed, Aug 13, 2003 at 09:05:58AM +1000, Neil Brown wrote: > > > On Tuesday August 12, akpm@osdl.org wrote: > > > > Tupshin Harper <tupshin@tupshin.com> wrote: > > > > > > > > > > raid0_make_request bug: can't convert block across chunks or bigger than > > > > > 8k 12436792 8 > > > > > > > Probably the simplest solution to this is to put in calls to > > > bio_split, which will need to be strengthed to handle multi-page bios. > > > > > > The policy would be: > > > "a client of a block device *should* honour the various bio size > > > restrictions, and may suffer performance loss if it doesn't; > > > a block device driver *must* handle any bio it is passed, and may > > > call bio_split to help out". > > > > > > > Any progress on this? > > No, and I doubt there will be in a big hurry, unless I come up with an > easy way to make lvm-over-raid0 break instantly instead of eventually. > > I think that for now you should assume tat lvm over raid0 (or raid0 > over lvm) simply isn't supported. As lvm (aka dm) supports striping, > it shouldn't be needed.
I have a raid5 with "4" 18gb drives, and one of the "drives" is two 9gb drives in a linear md "array".
I'm guessing this will hit this bug too?
I have a couple systems that use software raid5 that I'll avoid putting 2.6-test on until I know the raid is more reliable (or is this only with md+lvm?)
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |