Re: [2.6 patch] bio.c: make bio_destructor static

[Jeff V. Merkey]

Jens Axboe wrote:

> On Sat, Oct 30 2004, Adrian Bunk wrote:
>  
>
> > bio_destructor in fs/bio.c isn't used outside of this file, and after 
> > quickly thinking about it I didn't find a reason why it should.
> >
> > The patch below makes it static.
> >
> >
> > Signed-off-by: Adrian Bunk <bunk@xxxxxxxxx>
> >    
>
> Acked-by: Jens Axboe <axboe@xxxxxxx>
>
>  
>
> > --- linux-2.6.10-rc1-mm2-full/fs/bio.c.old	2004-10-30 13:53:41.000000000 +0200
> > +++ linux-2.6.10-rc1-mm2-full/fs/bio.c	2004-10-30 13:56:16.000000000 +0200
> > @@ -91,7 +91,7 @@
> > /*
> >  * default destructor for a bio allocated with bio_alloc()
> >  */
> > -void bio_destructor(struct bio *bio)
> > +static void bio_destructor(struct bio *bio)
> > {
> > 	const int pool_idx = BIO_POOL_IDX(bio);
> > 	struct biovec_pool *bp = bvec_array + pool_idx;
> >
> >
> >    
>
>  
Jens,

This change does not break me either. Seems benign. One thing to 
consider is the ability to remap
block addresses from bios for mv operations that occur across mount 
points. At present, do_rename
returns -EXDEV if someone attempts an mv operation accross mount points 
which point to
physical storage in the same system, and requires all the data copy up 
to user space then back
down. This seems wasteful of cycles and inefficient.

A better model, and one I have implemented in the dsfs file system (I 
changed do_rename extensively)
is to cache the mv'd file and alias the bio chain to point to the new 
disk location during mv commands,
even across mount points, and allow the data to DMA directly between 
local mount points without
moving the data up to user space and back down.

I am doing this with some heavy modifications, but I think it more 
appropriately should be a kernel
feature "fait acompli." The bio interface in the buffer cache (and some 
triggers in do rename) has to
be able to remap data chains to another device on the fly.

Why? If you are using remote Fiber Channel adapters that map storage 
local as SCSI it's super fast
and low cycle overhead to simply mv the files and have them dma out on 
the storage and skip the
inefficient user space copy.

Just a suggestion.

Jeff



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