Messages in this thread | | | From | Neil Brown <> | Date | Wed, 13 Aug 2003 09:05:58 +1000 | Subject | Re: data corruption using raid0+lvm2+jfs with 2.6.0-test3 |
| |
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 > > 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |