Switch to full style
CompactFlash, SD, MMC, USB flash storage. Anything that does not have moving parts inside.
Post a reply

A question about NAND Flash memory

December 17th, 2014, 11:37

In some cases, is it possible to edit a page without moving the whole Block. For example, let us have the word "HDD" in a single page; now we want to add the word "Forum" to it; to make it "HDD Forum". Is it necessary for the whole block containing the word "HDD" to be moved to another block ? Please note that, as far as Memory cells are concerned, there are no modification; there are just programming of additional Bits.

Thanks for any info.

Re: A question about NAND Flash memory

December 17th, 2014, 17:32

Is it possible, probably. Is it likely that the controller would be smart enough to know that it doesn't need to wipe the block, probably not.

Re: A question about NAND Flash memory

December 17th, 2014, 19:02

No, this can't be done exactly as you describe however you can do something similar with SLC NAND.

Re: A question about NAND Flash memory

December 18th, 2014, 8:43

data-medics,

Would the controller be smart enough if the bits to be programmed are in the service area ? If not, I believe that the cost to its "stupidity" will be enormous, as shown below.

jeremyb,

Could you please explain or link that "something similar" ?


No, this can't be done exactly as you describe however you can do something similar with SLC NAND.



If a Block has to be moved each time a single memory Cell is to be programmed, would not data writing be a cumbersome process. Take for example the following:

During Block writing, there are a series of programming processes that take place, one after another, in the new Block, like:

- Clearing the Free/Used Bit
- Block number writing
- Clearing the Pre-Valid/Valid Bit
- Clearing the Valid/Obsolute Bit etc.

Imagine the time spent and the wear caused if each of those sub-sets of a SINGLE WRITING PROCESS entail moving the block.

Re: A question about NAND Flash memory

December 18th, 2014, 22:48

I think what you describe is actually done by caching writes. So the data written would be written to a cache for a while, and if possible, subsequent writes may "merge" if possible, or some other type of optimisation, and after that write the block.

I am sure there are many different schemes, and unless you are going to study one particular scheme, it is all just conjecture.

Unless you are some kind of developer, the needed documentation for any scheme is probably not going to be available.

The controllers range from doing nothing but provide a FTL that writes block sequentially and provides basic ECC to advanced wear level schemes with good ECC, caching and enhancements like DDR.

Some storage technology also have schemes like de-duplication technology where a certain data structure is only ever written to disk(incl flash) once and subsequent writes are just pointers to that data.

Re: A question about NAND Flash memory

December 20th, 2014, 1:32

jeremyb wrote:No, this can't be done exactly as you describe however you can do something similar with SLC NAND.

SLC NAND lets you overwrite unset bits within a programed page without an erase operation but it opens up more problems than solutions (eg: SA, ECC, etc) but its the closest answer to match your exact question.

There are many solutions for your problem, the simplest being page level addressing instead of block level addressing which solves all your problems.

Re: A question about NAND Flash memory

December 21st, 2014, 17:01

Matiw wrote:In some cases, is it possible to edit a page without moving the whole Block. For example, let us have the word "HDD" in a single page; now we want to add the word "Forum" to it; to make it "HDD Forum". Is it necessary for the whole block containing the word "HDD" to be moved to another block ? Please note that, as far as Memory cells are concerned, there are no modification; there are just programming of additional Bits.

Thanks for any info.


Possible, and this is exacly how most flash controllers work. There are two types of blocks with data updates - Replacement blocks and LOG blocks.
When you want to edit page, controller moves "page update" to LOG block and stick it to main block. The main block keeps obsolete data (garbage), usually long time until lack of free blocks in NAND (forensic guys should say here "OMG". YES, EVEN FORMATTED FLASH DEVICE MAY CONTAIN USER DATA). Next modification of same data will produce next page update in same LOG block. So when you look into LOG block, sometimes you can see history (LOG) of user data modification. Of course, this is accessible through chip-off only. Here's proof of theory in series of pictures from one LOG block which belonged to file system (was a real case).

First update

Image

Second update

Image

Third update

Image

Fourth update

Image

Re: A question about NAND Flash memory

December 23rd, 2014, 7:10

Thanks HaQue and Sasha Sheremetov.

I think that both your replies are saying he same thing, apart from the wordings.

The last updated page from the Log Block is stuck to a replacement block (not the principal block), is not it ? In other words, those small one-bit updates to the System Area are done in the log-block; and the last updated page in the log-block is programmed (stuck) on to a replacement block. Thus there is only one or less block movement per data update.

This makes a lot of sense, than moving the original Block to another Block for every single-bit and small data updates.


Possible, and this is exacly how most flash controllers work. There are two types of blocks with data updates - Replacement blocks and LOG blocks.
When you want to edit page, controller moves "page update" to LOG block and stick it to main block. The main block keeps obsolete data (garbage), usually long time until lack of free blocks in NAND (forensic guys should say here "OMG". YES, EVEN FORMATTED FLASH DEVICE MAY CONTAIN USER DATA). Next modification of same data will produce next page update in same LOG block. So when you look into LOG block, sometimes you can see history (LOG) of user data modification. Of course, this is accessible through chip-off only. Here's proof of theory in series of pictures from one LOG block which belonged to file system (was a real case).
Post a reply