mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: lsorense@csclub.uwaterloo.ca (Lennart Sorensen)
To: linux@horizon.com
Cc: linux-kernel@vger.kernel.org
Subject: Re: Sync option destroys flash!
Date: Tue, 17 May 2005 09:36:06 -0400	[thread overview]
Message-ID: <20050517133606.GD23621@csclub.uwaterloo.ca> (raw)
In-Reply-To: <20050514024346.18045.qmail@science.horizon.com>

On Sat, May 14, 2005 at 02:43:46AM -0000, linux@horizon.com wrote:
> Alan the Hirsute spake unto the masses:
> > All non-shite quality flash keys have an on media log structured file
> > system and will take 100,000+ writes per sector or so. They decent ones
> > also map out bad blocks and have spares. The "wear out the same sector"
> > stuff is a myth except on ultra-crap devices.
> 
> I would have though so, but I can say from personal experience that
> SanDisk brand CF cards respond to losing power during a write by producing
> a bad sector.  I had assumed that a sensible implementation would take
> advantage of the out-of-place writing by doing a two-phase commit at
> write time, so writes would be atomic.

It can also respond to loosing power during write by getting it's state
so mixed up the whole card is dead (it identifies but all sectors fail
to read).  The binary industrial grade CF cards (no longer in
production) had capacitors to be able to finish writing the block they
were doing to prevent problems.  Supposedly their new firmware now will
have a rollback system so that any partial write is just added back to
the free pool.  I had thought this was always how they did it, but no
apparently that is also something new.

> Does anyone know of a CF manufacturer that *does* guarantee atomic writes?
> Obviously, if power is lost during a write, it's not clear whether
> I'll get the old or the new contents, but I want one or ther other and
> not -EIO.

We were told by SanDisk when we asked about a dead card (it had power
loss during a write) and was told that is normal for the regular
multicell flash cards.  They told us the firmware in the generation of
cards they are currently launching does not have a problem with that
anymore since it essentially journals the writes and can roll back a
partial block write.  I imagine they have patents on that too along with
lots of other flash technology.  Unfortunately their next generation
cards aren't -40 to +85C operation so although everything else was
perfect about them, they are of no use to us.

> Given that SanDisk first developed the CompactFlash card, you'd think they'd
> be a fairly reputable brand...

Well they seem to finally be getting those features working as people
have expected them to work.

Len Sorensen

  reply	other threads:[~2005-05-17 13:36 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-05-14  2:43 linux
2005-05-17 13:36 ` Lennart Sorensen [this message]
2005-05-17 20:31   ` linux
2005-05-17 20:43     ` Richard B. Johnson
2005-05-18 21:08       ` Sync option destroys flash! Now I'm confused Michael H. Warfield
2005-05-19 12:50         ` Richard B. Johnson
2005-05-18 13:37     ` Sync option destroys flash! Lennart Sorensen
  -- strict thread matches above, loose matches on Subject: below --
2005-05-18 11:13 linux
2005-05-18 12:01 ` Richard B. Johnson
     [not found] <43UT5-jT-3@gated-at.bofh.it>
2005-05-14  4:34 ` Robert Hancock
     [not found] <43Ldl-NM-25@gated-at.bofh.it>
     [not found] ` <43M9s-1B8-39@gated-at.bofh.it>
     [not found]   ` <43MCx-1UF-27@gated-at.bofh.it>
     [not found]     ` <43MVz-2hL-1@gated-at.bofh.it>
2005-05-13 23:59       ` Robert Hancock
2005-05-13 16:20 Michael H. Warfield
2005-05-13 17:17 ` Lennart Sorensen
2005-05-13 17:53   ` Michael H. Warfield
2005-05-13 18:09     ` Lennart Sorensen
2005-05-13 18:21       ` Michael H. Warfield
2005-05-13 18:26         ` Lennart Sorensen
2005-05-13 18:53           ` Michael H. Warfield
2005-05-13 17:58   ` Zan Lynx
2005-05-13 18:13     ` Lennart Sorensen
2005-05-13 18:40 ` Alan Cox
2005-05-13 19:10   ` Michael H. Warfield
2005-05-13 22:00     ` Alan Cox
2005-05-13 22:22       ` Måns Rullgård
2005-05-13 23:24         ` Jon Masters
2005-05-13 23:01       ` Jeffrey Hundstad
2005-05-13 23:27         ` Jon Masters
2005-05-14 10:17       ` Jörn Engel
2005-05-14  1:05   ` Michael H. Warfield
2005-05-17 13:30     ` Lennart Sorensen
2005-05-13 21:25 ` Lee Revell
2005-05-13 22:43   ` Alan Cox
2005-05-15 19:00 ` Denis Vlasenko
2005-05-16  0:23   ` Mark Lord
2005-05-16  9:29     ` David Woodhouse
2005-05-16 16:42       ` Pavel Machek
2005-05-16 13:01     ` Richard B. Johnson
2005-05-16 23:18   ` Helge Hafting
2005-05-18  7:03     ` Denis Vlasenko
2005-05-17  7:59 ` Colin Leroy

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=20050517133606.GD23621@csclub.uwaterloo.ca \
    --to=lsorense@csclub.uwaterloo.ca \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@horizon.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

all inboxes | Powered by JetHome®