SFFDC and blksize_size
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.
Quoted 3 lines · Simon Haynes
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.
Quoted 4 lines
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.
Signature · 1 line
dwmw2
Quoted 4 lines · Simon Haynes
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.
Signature · 1 line
Jens Axboe
Quoted 9 lines · Jens Axboe
Quoted 4 lines · Simon Haynes
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.
Signature · 1 line
dwmw2
Quoted 7 lines · David Woodhouse
Quoted 6 lines · Jens Axboe
Quoted 4 lines · Simon Haynes
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
Quoted 7 lines
Quoted 3 lines
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.
Signature · 1 line
Jens Axboe