Talk:Wear leveling
This article is rated Start-class on Wikipedia's content assessment scale. It is of interest to the following WikiProjects: | ||||||||||||||
|
Text and/or other creative content from Static Wear Leveling was copied or moved into Wear leveling with [permanent diff this edit]. The former page's history now serves to provide attribution for that content in the latter page, and it must not be deleted as long as the latter page exists. |
Attach PDF file
[edit]hi, information about wear leveling is sparse on the internet. Companies keep their algorithms as a secret. The white paper from sandisk is no exception. Sandisk removed the paper from all official pages so it's very hard to find (Try to search for it!). So I'd like to find a nice place to upload this paper to. Any suggestions where to archive it?
- Did you check whether the file is archived by The Wayback Machine? Brolin Empey 20:45, 12 May 2006 (UTC)
It's still available. Check http://www.sandisk.com/Assets/File/OEM/WhitePapersAndBrochures/RS-MMC/WPaperWearLevelv1.0.pdf
Tex (talk) 20:38, 5 March 2008 (UTC)
- Above link is currently 'DEAD', "The page cannot be found" --220 of Borg 19:37, 5 December 2011 (UTC)
- But a Google search for "Sandisk Wear leveling" got it here at http://www.d.umn.edu/~cprince/courses/osresources/news/WearLevel.pdf
"W H I T E P A P E R : S A N D I S K F L A S H M E M O R Y C A R D S - W E A R L E V E L I N G, October 2003", as the first result.
• Query: Is this linkable or a copy-vio?- 220 of Borg 19:48, 5 December 2011 (UTC)
- But a Google search for "Sandisk Wear leveling" got it here at http://www.d.umn.edu/~cprince/courses/osresources/news/WearLevel.pdf
- Answer (a year later): A link to copyrighted external data is no problem. But data should never be copied to WP, whether copyrighted or not, because WP is actually written by its editors, based on reliable sources. David Spector (talk) 21:46, 16 May 2013 (UTC)
Comment about FAT File system
[edit]The comment about the sandisk wear leveling not working for the FAT is incorrect, the comment assumes that the first 4Mb of the host visible sectors are in the same zone. This will definitely NOT be the case, any normal filesystem will tend to cluster writes in small areas of the 'disk' for performance reasons (on hard disk drives). This means that it the 'erase block' is one sector the best layout for a 4Mb zone on a 1Gb device is for every 256th sector to be in a given zone. The size of the 'erase block' does confuse this though.
I'm not sure if the paragraph should be rewritten or just deleted. 86.16.135.53 10:06, 27 May 2006 (UTC)
Comment about DiskonModule wear leveling
[edit]I disagree with "Some storage interfaces like DiskOnChip (which allows flash memory devices to emulate regular ATA disks) do not in themselves perform wear levelling."
From the Emphase website describing a Flash disk module 44-pin: "Wear-leveling algorithm to increase module lifetime"
http://www.emphase.com/fdm4400
- I'd like a reference for this too. Most commercially available parallel ATA flash modules use the CompactFlash form factor of ATA, and as I understand the article, most commercially available CF cards perform wear levelling. I've requested a citation, and I plan to come back in a week and remove the claim if nobody cites it. --Damian Yerrick (talk | stalk) 12:59, 17 July 2007 (UTC)
- By now, 2.5" and 3.5" flash solid-state drives based on SATA or parallel ATA have become common, but the controllers on these are even less size-constrained than CF and thus more likely to wear-level their physical medium. --Damian Yerrick (talk | stalk) 16:53, 11 September 2009 (UTC)
SD and compact flash wear leveling
[edit]Does anyone have a reference for the article's claim that the SD standard uses wear leveling? —Preceding unsigned comment added by 216.75.169.65 (talk) 23:19, 17 August 2008 (UTC)
- I don't see any claim in the article that the Secure Digital spec requires wear levelling, just that cards do use it. SD is just a protocol and three form factors; I don't think it specifies any methods of wear levelling. But any card that doesn't use it will likely get trashed in the market. --Damian Yerrick (talk | stalk) 00:59, 18 August 2008 (UTC)
- That doesn't seem to have happened. SmartMedia didn't have wear levelling, though that card is now obsolete. The xD card is in reality just a miniaturised SmartMadia card. It is electrically identical right down to the lack of wear levelling controller because the host device has to communicate with flash chip directly. Some SmartMedia devices can use the smaller xD cards via an adaptor (geometry being the only limitation as the xD card is thicker). It is still firmly in the market place though only a minority of devices use it. 20.133.0.13 (talk) 12:35, 10 September 2009 (UTC)
- But in fact, xD has been trashed by SD. See the lead of xD-Picture Card: even Olympus and Fuji are moving to SDHC. Feel free to close your eyes and laugh out loud. --Damian Yerrick (talk | stalk) 17:03, 11 September 2009 (UTC)
- That doesn't seem to have happened. SmartMedia didn't have wear levelling, though that card is now obsolete. The xD card is in reality just a miniaturised SmartMadia card. It is electrically identical right down to the lack of wear levelling controller because the host device has to communicate with flash chip directly. Some SmartMedia devices can use the smaller xD cards via an adaptor (geometry being the only limitation as the xD card is thicker). It is still firmly in the market place though only a minority of devices use it. 20.133.0.13 (talk) 12:35, 10 September 2009 (UTC)
Different Wear Levelling Algorithms Not Discussed
[edit]This article omits specific mention of significant differences in algorithms used to perform wear levelling, or, to be specific, the difference between dynamic wear levelling and Static Wear Levelling.[1] 68.177.173.34 (talk) 20:16, 29 January 2010 (UTC)
- This has apparently been fixed. David Spector (talk) 21:49, 16 May 2013 (UTC)
Spelling question
[edit]What is the rationale for the double "l"? None of the references cited use it; a search on Google for "define:levell" shows no results and a regular search returns references only to its use as a family name. Would it not be more appropriate for this page to redirect to "Wear leveling" rather than the other way around? Apologies if I'm being USA-centric, but I did try to figure out why this spelling was being promoted here. Dave Brown (talk) 21:41, 7 March 2010 (UTC)
- Initially I had the same impression on this spelling issue and I also was concerned maybe I had a USA-centric view of the spelling. As of 31 May 2010:
Search Wear Levelling Wear Leveling Google Search ~10,200 ~95,400 Micron.com 3 621 Intel.com 105 348 Samsung.com 161 96 Toshiba.com 0 44 Hynix.com 0 20 SanDisk.com 23 195 IBM.com 291 491 STEC-inc.com 4 164 FusionIO.com 1 4 Storagesearch.com 6 174
- From my perspective the last entry is the clincher. Storagesearch.com is a site dedicated to storage technology for over 10 years with a focus on SSDs and Flash memory technology. The site editor is a British resident, Zsolt Kerekes. If all the major Flash memory suppliers and notable flash memory users who have a relationship with SSDs spell "Wear Leveling" with one "l" I would say the Wikipedia entry should default to the most common spelling for this usage. Music Sorter (talk) 21:49, 31 May 2010 (UTC)
- The single/double L spelling is a national variety. Because this article is now already quite mature the WP policy is not to change the spelling to suit our own desires. See Wikipedia:Manual_of_Style#National_varieties_of_English. HumphreyW (talk) 08:43, 1 June 2010 (UTC)
- HumphreyW, thanks for pointing out the WP policy note on national style. That seems like a reasonable rule to follow. It makes even more sense that the initial creator of this page selected double L and therefore that should be the style used. Now at the risk of sounding argumentative, I am curious if this case might be different in some way from the intent of the style guide and it should be considered as a proposed change in this article (and possibly added as an exception to the style guide as a different situation). Consider the following points:
- The word itself is a key part of the article, not a word selected arbitrarily to describe or explain it. In fact the article is a term or phrase used to describe a feature of Solid-state drives and Flash memory.
- All 5 links and references in this article spell the word with one L.
- The recommendation in Wikipedia:Manual_of_Style#Consistency_within_articles would suggest all spellings be consistent. Since we cannot change the source to match the page, we should match the page to the source.
- The same recommendation also states we should use the spelling in a quotation. I understand we are not quoting the source specifically, but we are using the term they spelled with one L.
- The highly-related article Solid-state drive uses the term 9 separate times with a single L.
- Another highly-related article Write amplification has 10 sources referenced and all use the single L throughout the documents.
- Although the article has existed for 7 years and Wikipedia:Manual_of_Style#Retaining_the_existing_variety recommends to not make a change, it is a very small article with just over 500 words and does not appear to be highly evolved as defined in the style guide.
- The point I made earlier is also applicable here. Storagesearch.com is a site that has been dedicated to storage technology for years. The editor is a British resident and recognizes that the spelling for the term "Wear Leveling" is not a national variety, but a name of a feature.
- I propose that this particular case is not simply a case to change the spelling to suit our own desires, but rather a desire to match our article to the spelling of the term, wear leveling, as defined and spelled by the very sources we are citing. Music Sorter (talk) 21:36, 2 June 2010 (UTC)
- I agree. By now it appears that the semiconductor companies involved in SSD controller design have ties to countries where U.S. English is written, and we have a guideline about such ties. --Damian Yerrick (talk | stalk) 01:10, 3 June 2010 (UTC)
References
[edit]Unused content from original Static Wear Leveling article
[edit]The content below was pulled from the original Static wear leveling article before it was merged with this one. Original comments on this talk page identified this article as being too technical and not truly descriptive of Static wear leveling. If anyone finds data here that they believe is useful in the new combined main article please add it and note what is covered by marking out the text here. § Music Sorter § (talk) 00:02, 14 August 2010 (UTC)
{{articleissues| article=y| context=December 2007| technical=June 2008}}
Static Wear Leveling (SWL) is a process that alleviates the problem of short–life flash memory by introducing a process to copy data from the volatile flash memory in a cleaning process to minimise the number of read and write operations and so extend the length of NAND memory life. The problem arose when more recent flash memory lifespan was reduced from 100,000 (in SLC) to 10,000 (in MLC) erase processes.
Outline
[edit]Applications of NAND flash memory have grown beyond their original design goals. For instance Intel Turbo Memory uses flash memory as the cache of hard disks and Microsoft's ReadyBoost uses flash memory to accelerate the boot sequence of Windows Vista. These developments challenge the reliability and endurance of flash memory. The reliability problem becomes even more challenging when low-cost flash-memory designs gain momentum in the market. For example the endurance of a block of Multi-level Cell(MLC) flash memory is only 10,000 erase counts or even lower compared to the 100,000 erase counts of Single-level cell (SLC) flash memory. Static Wear leveling helps maintain crucial reliability while limiting impacts on performance and cost.
Overview
[edit]Consider a typical system architecture of flash-memory-based file systems as shown in the following figure. A Memory Technology Device (MTD) driver is to provide primitive functions, such as read, write, and erase over flash memory. A Flash Translation Layer (FTL) driver is needed in the system for address translation and garbage collection, and FTL and NFTL are its popular implementations. A typical FTL driver consists of an allocator and a cleaner. The Allocator handles any translation of Logical Block Addresses (LBA) and their Physical Block Addresses (PBA).
Different approaches have different address translation mechanisms, such as FTL and NAND Flash Translation Layer (NFTL). The cleaner is designed to reclaim pages of invalid data. Since collection is done in the unit of a block, valid data in any pages of a block must be copied to other free pages when the block is to be erased. One important implementation issue for flash-memory management is Wear leveling which is to evenly distribute the number of erasures performed for each block, because of the limited erasure lifespan of individual cells. The Static Wear Leveler (SWL) is to distribute block erasures over blocks evenly. The motivation of static wear leveling is to prevent any cold data from staying at any block for a long period of time. It is to minimize the maximum erase-count difference of any two blocks so that the lifetime of flash memory is extended. In order to minimize the integration overhead, consider a modular design for static wear leveling as very important.
Static Wear Leveler example
[edit]Let the Static Wear Leveler (SWL) be associated with a Block Erasing Table (BET) to remember which block has been erased in a selected period of time. The SWL is activated by some system parameters for the needs of static wear leveling. When the SWL is running it either resets the BET or picks up a block that has not been erased so far, based on the BET information, and triggers the cleaner to do garbage collection on the block. The selection procedure of a block must be done in an efficient way within a bounded amount of time. Note that the BET must be updated whenever a block is erased. It could be done by a triggering action to the SWL. The design of the BET must be scalable because of the rapid increasing of flash-memory capacity and the limited RAM space on a controller. Whenever a block is recycled by garbage collection any modification to the address translation is done as the original design of an FTL driver. The implementation of the SWL could be a thread or a procedure triggered by a timer or the allocator/cleaner based on some preset conditions.
The SWL is invoked by the cleaner to update the BET whenever any block is erased by the cleaner in garbage collection when SWL is needed. We can use two variables to keep track of the total number of block erases done since the BET is reset and the number of 1’s in the BET. If the ratio of the two tracked numbers is too high the SWL is triggered to move cold data from their original places by requesting the cleaner to reclaim those blocks whose corresponding bit in the BET is 0.
Block Erasing Table
[edit]The purpose of the Block Erasing Table (BET) is to remember which block has been erased in a pre-determined time frame, referred to as the resetting interval, so as to locate blocks of cold data. A BET is a bit array in which each bit corresponds to a set of 2k contiguous blocks where k is an integer that is greater than or equal to 0. Whenever a block is erased by the cleaner the SWL is triggered to set the corresponding bit as 1.
References
[edit]<references />
External links
[edit]- Open NAND Flash Interface Working Group
- Flash-Memory Research Group
- A Nonvolatile Memory Overview
- SanDisk Flash Memory Plant
- An Efficient StaticWear Levelling Design to Enhance the Endurance of Flash-Memory Storage Systems
- What is NAND Flash
- NAND Flash Applications
Wear leveling mapping blocks wear out first
[edit]I am not yet able to find an answer to this question regarding wear leveling:
For the NAND flash memory (flash drive) to be transparent to the OS, it needs to have a controller on the chip and store a wear level mapping (LBA to PBA) on the device. The question is, where is such mapping table stored?
If the mapping table is also stored on the flash memory, it needs to be updated every time a write command is received. Therefore, the blocks that store the mapping table will wear out first, while other data blocks are not worn out yet. — Preceding unsigned comment added by 131.107.0.81 (talk) 23:16, 30 December 2011 (UTC)
- This is not a forum. The answer to your question is dependant upon which exact device you are using, they all different. HumphreyW (talk) 00:02, 31 December 2011 (UTC)
Size of one remapped block
[edit]The article could detail what is the size of one remapped data chunk. I assume it can't be very small as then all the remapping data would consume enormous amount of space. 84.248.91.142 (talk) 16:28, 28 September 2012 (UTC)
- Each system is different. There is no predefined size that everything uses. HumphreyW (talk) 01:19, 29 September 2012 (UTC)
"Least Frequently Used" Should be used instead of "Least Recently Used"
[edit]You have wrote that "Blocks or sectors on the media can be tracked in a least recently used queue of some sort."
I disagree with least recently used queue of some sort and I think it should be least frequently used queue. Also LFU can be categorized as one of LRU algorithms but I think other LRU algorithms (e.g. Aging) are not suitable for this purpose, because unlike paging applications that try to replace the least recently used page, here exactly the least frequently used block/sector should be rewritten, since number of writing operations accumulate over time.
e.g. If block A was written 1000times 1 year ago and block B was written exactly 1 time 1ms ago, LRU will choose block A for rewriting which is not optimum but LFU will choose block B which is better choice.
My claim could be false only if you bring a practical example of a kind of LRU which is used as proper algorithm in real life. --digitsm (talk) 01:56, 26 November 2013 (UTC)
- You're right, thank you for pointing that out. Already went ahead and edited the article, please check it out. — Dsimic (talk) 02:42, 26 November 2013 (UTC)