public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: David Woodhouse <dwmw2@infradead.org>
To: simon@baydel.com
Cc: linux-mtd@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Subject: Re: SFFDC and blksize_size
Date: Fri, 07 Nov 2003 14:18:35 +0000	[thread overview]
Message-ID: <1068214714.6065.887.camel@hades.cambridge.redhat.com> (raw)
In-Reply-To: <37CC93E8710D@baydel.com>

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

  reply	other threads:[~2003-11-07 14:18 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-11-07 13:12 SFFDC and blksize_size Simon Haynes
2003-11-07 14:18 ` David Woodhouse [this message]
2003-11-10 14:09 ` Jens Axboe
2003-11-10 14:17   ` David Woodhouse
2003-11-10 14:23     ` Jens Axboe

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1068214714.6065.887.camel@hades.cambridge.redhat.com \
    --to=dwmw2@infradead.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=simon@baydel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox