public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Pierre Ossman <drzeus-list@drzeus.cx>
To: LKML <linux-kernel@vger.kernel.org>
Subject: Flash erase groups and filesystems
Date: Mon, 15 Aug 2005 22:21:55 +0200	[thread overview]
Message-ID: <4300F963.5040905@drzeus.cx> (raw)

If you know how flash erase groups behave then skip a bit ;)

As you may or may not be aware, flash memory tends to be designed so
that only large groups of sectors can be erased at a time. For most
systems this is handled automatically by having the onboard controller
caching everyhing but the sector being overwritten. If you write a
single sector at a time (or if the controller is stupid) this will
result in the flash being erased several times because of writes in
sectors close by. The end result being that your flash is worn out faster.

--8<--- skip to here ----

To minimise the number of erases the MMC protocol supports pre-erasing
blocks before you actually write to them. Now what I'm unclear on is how
this will interact with filesystems and the assumptions they make.

If the controller gets a request to write 128 sectors and this fails
after 20 sectors, the remaining 108 sectors will still have lost their
data because of the pre-erase. Will this break assumptions made in the
VFS layer? I.e. does it assume that only the failed sector has unknown data?

I'm writing a patch that gives this functionality to the MMC layer and
since I'm no VFS expert I need some input into any side effects.

Rgds
Pierre

             reply	other threads:[~2005-08-15 20:21 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-08-15 20:21 Pierre Ossman [this message]
2005-08-16 16:27 ` Flash erase groups and filesystems Jörn Engel
2005-08-16 17:09   ` Pierre Ossman
2005-08-16 18:13     ` Jörn Engel
2005-08-16 18:52       ` Jörn Engel
2005-08-17 11:35         ` Pierre Ossman
2005-08-17 11:45           ` Jörn Engel
2005-08-17 14:35     ` Pavel Machek
2005-08-18 11:09       ` linux-os (Dick Johnson)

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=4300F963.5040905@drzeus.cx \
    --to=drzeus-list@drzeus.cx \
    --cc=linux-kernel@vger.kernel.org \
    /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