I have been writing a block driver for SSFDC compliant SMC cards. This stuff
allocates 16k blocks. When I get requests the transfers are split into the
size I specifty in the blksize_size{MAJOR] array. It sems that most things
set this to 1k. In my case this causes a performance problem as I have to
end up doing 16 * (16K write, 16K read, 16k erase) to write and verify a
16k block which has been previously written.
I increased this size to 4k and now I only need 4 * this lot. !deally I would
like to do 1. However if I set the block size to 16k the module installation
crashes when I call register_disk.
I guess I could deal with the request queue myself but I would just like to
know if there is a 4k limit or I have some other bug.
Many Thanks
Simon.
On Fri, 2003-11-07 at 13:12 +0000, Simon Haynes wrote:
> I have been writing a block driver for SSFDC compliant SMC cards. This stuff
> allocates 16k blocks. When I get requests the transfers are split into the
> size I specifty in the blksize_size{MAJOR] array.
You can't set a block size larger than page size.
> It sems that most things
> set this to 1k. In my case this causes a performance problem as I have to
> end up doing 16 * (16K write, 16K read, 16k erase) to write and verify a
> 16k block which has been previously written.
Urgh. Whereas with FTL, NFTL etc. you can just fill in new sectors
individually in the newly-allocated eraseblock.
Surely you're not actually erasing the block and then praying you don't
lose power before writing the new contents back? There's some kind of
chaining from the old to the new block? Can't you say which sectors are
valid in the new block, and which should still be used from the old?
I wouldn't advocate setting the block size even to 4KiB, since that'll
waste a lot of space. But we could certainly make use of request merging
if what you're doing really is necessary -- we can make a
'write_sectors' function which writes more than a sector at a time.
--
dwmw2
On Mon, 2003-11-10 at 15:09 +0100, Jens Axboe wrote:
> On Fri, Nov 07 2003, Simon Haynes wrote:
> >
> > I have been writing a block driver for SSFDC compliant SMC cards. This stuff
> > allocates 16k blocks. When I get requests the transfers are split into the
> > size I specifty in the blksize_size{MAJOR] array. It sems that most things
>
> Sounds like a bad way to do it. It's much better to prevent builds of
> bigger requests than you can handle in one go. You don't mention what
> kernel you are using, but both 2.4 and 2.6 can do this for you.
The problem is the other way round -- he wants request merging, and he's
achieving this by setting the block size higher.... and observing a
crash when he sets his block size higher than PAGE_SIZE.
--
dwmw2
On Fri, Nov 07 2003, Simon Haynes wrote:
>
> I have been writing a block driver for SSFDC compliant SMC cards. This stuff
> allocates 16k blocks. When I get requests the transfers are split into the
> size I specifty in the blksize_size{MAJOR] array. It sems that most things
Sounds like a bad way to do it. It's much better to prevent builds of
bigger requests than you can handle in one go. You don't mention what
kernel you are using, but both 2.4 and 2.6 can do this for you.
--
Jens Axboe
On Mon, Nov 10 2003, David Woodhouse wrote:
> On Mon, 2003-11-10 at 15:09 +0100, Jens Axboe wrote:
> > On Fri, Nov 07 2003, Simon Haynes wrote:
> > >
> > > I have been writing a block driver for SSFDC compliant SMC cards. This stuff
> > > allocates 16k blocks. When I get requests the transfers are split into the
> > > size I specifty in the blksize_size{MAJOR] array. It sems that most things
> >
> > Sounds like a bad way to do it. It's much better to prevent builds of
> > bigger requests than you can handle in one go. You don't mention what
> > kernel you are using, but both 2.4 and 2.6 can do this for you.
>
> The problem is the other way round -- he wants request merging, and he's
> achieving this by setting the block size higher.... and observing a
> crash when he sets his block size higher than PAGE_SIZE.
Yes I know, but he doesn't want requests merged > 16k, right? So it's
stupid to allow these to get through.
--
Jens Axboe