public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Sergei Organov <osv@javad.com>
To: "Magnus Damm" <magnus.damm@gmail.com>
Cc: "linux-os (Dick Johnson)" <linux-os@analogic.com>,
	"Artem B. Bityutskiy" <dedekind@yandex.ru>,
	linux@horizon.com, kalin@thinrope.net,
	linux-kernel@vger.kernel.org
Subject: Re: Lifetime of flash memory
Date: Tue, 28 Mar 2006 12:58:54 +0400	[thread overview]
Message-ID: <87zmjb54j5.fsf@javad.com> (raw)
In-Reply-To: <aec7e5c30603272241n5c07aa0csd52b237aaaeb30d6@mail.gmail.com> (Magnus Damm's message of "Tue, 28 Mar 2006 15:41:53 +0900")

"Magnus Damm" <magnus.damm@gmail.com> writes:

> On 3/28/06, Sergei Organov <s.organov@javad.com> wrote:
>> "linux-os \(Dick Johnson\)" <linux-os@analogic.com> writes:
>> > Note that the actual block size is usually 64k, not the 512 bytes of a
>> > 'sector'. Apparently, some of the data-space on each block is used for
>> > relocation and logical-to-physical mapping.
>>
>> Wrong. AFAIK, first disks had FLASH with 512b blocks, then next
>> generation had 16K blocks, and currently most of cards have 128K
>> blocks. Besides, each page of a block (64 pages * 2K for 128K block) has
>> additional "system" area of 64 bytes. One thing that is in the system
>> area is bad block indicator (2 bytes) to mark some blocks as bad on
>> factory, and the rest could be used by application[1] the same way the
>> rest of the page is used. So physical block size is in fact 64 * (2048 +
>> 64) = 135168 bytes.
>
> Doesn't this depend on if we are talking about NOR or NAND memory? It
> looks like you are describing some kind of NAND memory. Also I guess
> it varies with manufacturer.

Yes, I talk about NAND FLASH as I've never seen CF cards based on NOR FLASH,
-- NOR FLASH write times and capacities are just too poor, I think.

> When it comes to CF the internal block size doesn't really matter
> because the CF controller will hide it for you. The controller will
> perform some kind of mapping between the 512 byte based IDE-interface
> and it's internal sector size. This together with wear levelling.

Yes, it will, but it can't entirely hide internal block size from you,
-- just compare write times for random access against write times for
sequential access. Old SanDisk CF cards based on NAND FLASH with 512b
blocks had these times roughly the same, and all recent CF cards that
I've tested have very big difference.

-- Sergei.

  reply	other threads:[~2006-03-28  8:59 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-03-23  7:49 Lifetime of flash memory linux
2006-03-26 13:55 ` Artem B. Bityutskiy
2006-03-26 16:21   ` linux
2006-03-26 16:36     ` Artem B. Bityutskiy
2006-03-27 16:18       ` Lennart Sorensen
2006-03-27 17:44         ` linux-os (Dick Johnson)
2006-03-27 18:01           ` Lennart Sorensen
2006-03-28  4:28           ` Sergei Organov
2006-03-28  6:41             ` Magnus Damm
2006-03-28  8:58               ` Sergei Organov [this message]
2006-03-28 12:55             ` linux-os (Dick Johnson)
2006-03-28 13:27               ` Sergei Organov
2006-03-28 13:35               ` Sergei Organov
2006-03-29  1:01             ` linux
2006-03-29  4:33               ` Sergei Organov
2006-03-29 15:56                 ` linux
2006-03-30  6:33                   ` Sergei Organov
2006-03-30 11:23                     ` linux
2006-03-30 12:18                       ` Sergei Organov
2006-03-28  0:21 ` Bill Davidsen
  -- strict thread matches above, loose matches on Subject: below --
2006-03-21 17:01 John Richard Moser
2006-03-21 17:14 ` David Vrabel
2006-03-21 17:28   ` John Richard Moser
2006-03-21 18:37     ` Paulo Marques
2006-03-21 18:00   ` hackmiester / Hunter Fuller
2006-03-21 18:20 ` Joshua Kugler
2006-03-21 18:40   ` John Richard Moser
2006-03-23  3:46 ` Kalin KOZHUHAROV

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=87zmjb54j5.fsf@javad.com \
    --to=osv@javad.com \
    --cc=dedekind@yandex.ru \
    --cc=kalin@thinrope.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-os@analogic.com \
    --cc=linux@horizon.com \
    --cc=magnus.damm@gmail.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