lkml.org 
[lkml]   [2003]   [Aug]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 13:47    [W:0.179 / U:0.184 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site