Jens Axboe wrote:
On 2011-03-12 14:33, Arne Jansen wrote:
Jens Axboe wrote:
On 2011-03-12 10:29, Arne Jansen wrote:
Hi,
I'm trying to re-use struct bio after completion, including the
allocated pages. Normally I re-initialize the fields bi_sector,
bi_size, bi_next, bi_flags, bi_comp_cpu and bi_bdev.
This works perfectly well, as long as no media errors are encountered.
After a media error, all subsequent reads with this bio fail. Are
there any more fields that need to get re-initialized? Or, better,
is there a function to reset the bio?
bio_init()? Sounds like you are not setting BIO_UPTODATE when resetting
it.
bio_init does way too much, as it discards the io_vec, refcnt, destructor,
private etc.
I set the flags to 1 << BIO_UPTODATE, but that proved to be fatal, too, as
it clobbers the POOL_FLAGS, which leads to an oops when the last reference
drops. These bio-beasts are just not made to be reused. One needs way too
much internal knowledge to reinitialize them properly.
Therefore, I'd really like to have a call like bio_reinit, which keeps the
io_vec and all the owners private information, but resets the parts that
get used by the stack like bi_next. Would that make sense?
The thing is, you can't really reuse without violating the allocator
principle of finite life times. Otherwise you risk hanging the system.
If you want to reuse, the bio should come out of your own pool or
through the bio_kmalloc() interface, not from bio_alloc() with the
default pool.
So there is no reinit, as there hasn't been a good use case for that.
The fact that flags has pool information in the top bits is a sure sign
you are violating that.
ok, assuming I allocate them with bio_kmalloc, the problem of reinit would
remain. Now that I own them, I can't reuse them.
This particular use case here is a scrub for btrfs. I have a limited set of
bios and pages, that I reuse as long as the scrub runs. Of course I could
just free up and reallocate everything after each read, but as I know how
much work there is ahead, I can just as well keep them.
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
