Re: data corruption using raid0+lvm2+jfs with 2.6.0-test3

[Neil Brown]

On Tuesday August 12, akpm@xxxxxxxx wrote:
> Tupshin Harper <tupshin@xxxxxxxxxxx> wrote:
> >
> > raid0_make_request bug: can't convert block across chunks or bigger than 
> > 8k 12436792 8
> 
> There is a fix for this at
> 
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.0-test3/2.6.0-test3-mm1/broken-out/bio-too-big-fix.patch
> 
> Results of testing are always appreciated...

I don't think this will help.  It is a different problem.

As far as I can tell, the problem is that dm doesn't honour the
merge_bvec_fn of the underlying device (neither does md for that
matter).
I think it does honour the max_sectors restriction, so it will only
allow a request as big as one chunk, but it will allow such a requests
to span a chunk boundary.

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".

A better solution, which is too much for 2.6.0, is to have a cleaner
interface wherein the client of the block device uses a two-stage
process to submit requests.
Firstly it says:
  I want to do IO at this location, what is the max number of sectors
  allowed?
Then it adds pages to the bio upto that limit. 
Finally it say
  OK, here is the request.

The first and final stages have to be properly paired so that a
device knows if there are any pending requests and can hold-off any
device reconfiguration until all pending requests have completed.

NeilBrown
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/