Re: ext2 on a CD-RW

From: Jens Axboe
Date: Fri Jan 02 2004 - 06:00:15 EST


On Fri, Jan 02 2004, Peter Osterlund wrote:
> Arjan van de Ven <arjanv@xxxxxxxxxx> writes:
>
> > On Fri, 2004-01-02 at 02:30, Peter Osterlund wrote:
> >
> > > The packet writing code has the restriction that a bio must not span a
> > > packet boundary. (A packet is 32*2048 bytes.) If the page when mapped
> > > to disk starts 2kb before a packet boundary, merge_bvec_fn therefore
> > > returns 2048, which is less than len, which is 4096 if the whole page
> > > is mapped, so the bio_add_page() call fails.
> >
> > devicemapper has similar restrictions for raid0 format; in that case
> > it's device-mappers job to split the page/bio. Just as it is UDF's task
> > to do the same I suspect...
>
> Old versions of the packet writing code did just that, but Jens told
> me that bio splitting was evil, so when the merge_bvec_fn
> functionality was added to the kernel, I started to use it.
>
> http://lists.suse.com/archive/packet-writing/2002-Aug/0044.html

Splitting is evil, but unfortunately it's a necessary evil... There are
a few kernel helpers to make supporting it easier (see bio_split()). Not
so sure how well that'll work for you, you may have to do the grunt work
yourself.

> If merge_bvec_fn is not supposed to be able to handle the need of the
> packet writing code, I can certainly resurrect my bio splitting code.

Only partially. Read my email: you _must_ accept a page addition to an
empty bio. You can refuse others. For the single page case, you may need
to split.

> Btw, for some reason, this bug is not triggered when using the UDF
> filesystem on a CDRW. I've only seen it with the ext2 filesystem.

Does UDF use mpage? The fact that it doesn't trigger on UDF doesn't mean
that packet writing isn't breaking the API :)

--
Jens Axboe

-
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/