lkml.org 
[lkml]   [2004]   [Nov]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [2.6 patch] bio.c: make bio_destructor static
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@stusta.de>
>>
>>
>
>Acked-by: Jens Axboe <axboe@suse.de>
>
>
>
>>--- 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@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:07    [W:0.035 / U:1.172 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site