Talk:Flash file system
This is the talk page for discussing improvements to the Flash file system article. This is not a forum for general discussion of the article's subject. |
Article policies
|
Find sources: Google (books · news · scholar · free images · WP refs) · FENS · JSTOR · TWL |
This article is rated Start-class on Wikipedia's content assessment scale. It is of interest to the following WikiProjects: | ||||||||||||||||||||||||
|
The contents of the True flash file system page were merged into Flash file system. For the contribution history and old versions of the redirected page, please see its history; for the discussion at that location, see its talk page. |
difference between filesystem for NOR memory and NAND memory
[edit]What is difference between filesystems for NOR memory and NAND memory? Could someone explain it in article?
For example: JFFS is for NOR, ETFS is for NAND, JFFS2 and YAFFS are for both NOR and NAND.
148.81.137.4 (talk) 17:32, 30 April 2009 (UTC)
- I'm late to reply, but please see NOR flash#Distinction between NOR and NAND flash. -- intgr [talk] 10:23, 26 October 2009 (UTC)
Limited benefits of Flash file system for UFDs?
[edit]"Removable flash memory cards and USB flash drives have built-in controllers to perform wear leveling and error correction so use of a flash file system has limited benefit."
What are these benefits? Insterested (talk) 08:32, 13 July 2010 (UTC)
- Potentially performance, because most disk file systems are tuned for rotating media. But I think the quote above is false; to my knowledge simple flash memory cards and USB sticks do not have wear levelling; only true SSDs do wear levelling. I have added a citation request to that claim. -- intgr [talk] 02:46, 14 July 2010 (UTC)
Flash File System - Invention & Early Implementations
[edit]Re: Wikipedia update for Flash File System October 14, 2010
Hello, I am writing a little more history for your entry on flash file system. This is autobiographical but not “original work” since it sets forth verifiable facts. My manager at the time of this work at Intel Corporation was Bruce McCormick. To verify the details regarding the patent work, you can contact Bruce at Intel in Folsom, California.
Kurt B. Robinson was the inventor of the flash file system in the 1989 to 1990 timeframe with an initial patent application filing of Dec. 31,1990, serial # 636238. This application was eventually split into 3 separate applications, resulting in the two fundamental patents: 1) #5592669 “File structure for a non-volatile block-erasable semiconductor flash memory” filed 12/1/95 and issued 1/7/97, and 2) #5544356 “Block-erasable non-volatile semiconductor memory which tracks and stores the total number of write/erase cycles for each block,” filed 3/3/95 and issued 8/6/96. Here you see the concepts of wear leveling cleanup operations as noted in the Wikipedia article for flash file system: here, from the first patent – “(1) tracking a number of times a portion of the memory has been cycled and storing the number as a cycle count in an allocated fourth portion of the memory; (2) minimizing cycling distributions between physical erase blocks of the memory by choosing for reclamation a portion of the memory with a lowest cycle count”. Kurt developed the theoretical performance models and these fundamental concepts and was, in fact, the only one in the organization at the time who believed that a flash file system could be constructed entirely with the large-block flash memory. Two other inventors are listed on these patents, Dale Elbert and Markus Levy, but their work was focused on hybrid memory arrays using either SRAM or byte-alterable EEPROM. Another patent of Kurt’s gives more detail on the required clean-up operation, #5682497, “Managing file structures for a flash memory file system in a computer.” Subsequent development verified Kurt’s assertion that a file system was feasible in 100% flash-memory array.
Original concepts had directory information stored in dedicated, cycleable blocks, but the subsequent, successful implementations held directory information in the same data blocks. Kurt worked with Microsoft for both the original FFS and FFS2 implementations. They were not widely accepted because they required mounting a separate, unique filing system to the operating system. An Intel inventor, Gerald Holtzhammer, named Kurt as a co-inventor of another patent which improved on this: #5630093, “Disk emulation for a non-volatile semiconductor memory utilizing a mapping table,” filed 4/19/96 and issued 5/13/97. Gerald’s base concept was the use of a “mapping table” that allowed flash data blocks to be mapped more directly to their analogous disk allocation units, the core concept enabling subsequent disk-logical-equivalent implementations. Kurt is also named as an inventor on several related flash file system and solid state disk patents, including “Sector-based storage device emulator having variable-sized sector” [#5822781] and “Addressing modes for a dynamic single bit per cell to multiple bit per cell memory [#5515317 & 5574879]
Kurt managed the development of the “Exchangeable Card Architecture” specification at Intel that became the basis of Socket Services and Card Services software layers along with the base PCMCIA card hardware interface when I/O functions were added to the original memory-only standard. Various groups at Intel developed related software for the PCMCIA Cards they were creating. This work outlined the resource “registry” concept and the basic software was incorporated into Microsoft’s “plug-and-play” in Windows 95. Kurt was active in the PCMCIA group as it attempted to standardize flash file systems – the FTL concept, etc. The cleanest implementation was from M-Systems, the TFFS. It was called the “True” Flash File System because the software interface it presented allowed it attached to any operating system using existing files systems with TFFS presenting a disk-compatible lower-level interface, using “plain” flash memory arrays like the original PCMCIA flash cards and USB flash memory sticks. This is conceptually how all flash disks are implemented today, including higher density devices employing multiple-bit-per-cell flash memory.
Respectfully submitted, Kurt B. Robinson, Newcastle, Ca. --Kurtbrobinson (talk) 18:40, 19 October 2010 (UTC)--Kurtbrobinson
File systems: how do FAT systems relate to FFS systems?
[edit]The article USB flash drive talks about FAT being used on flash. That article has a link to this one which talks about a set of file systems with completely different names. Are these 2 sets of file systems alternatives to each other, or are they at different levels? Could someone put in an explanation please? FrankSier (talk) 13:44, 18 February 2012 (UTC)
- See Talk:USB_flash_drive#File_system for further discussion. FrankSier (talk) 14:21, 18 February 2012 (UTC)
UBIFS is the successor of JFFS2
[edit]UBIFS should be mentioned in the places JFFS/JFFS2/etc is mentioned as it is "a successor to JFFS2".
70.60.53.140 (talk) 13:18, 21 March 2012 (UTC)
Should F2FS be in the article at all?
[edit]F2FS is a block oriented filesystem intended to be used on top of a Flash Translation Layer . See http://lkml.iu.edu//hypermail/linux/kernel/1210.0/03931.html :
"F2FS is not flash oriented filesystem as JFFS2, YAFFS2, UBIFS but block-oriented filesystem. So, F2FS design is restricted by block-layer's opportunities in the using of flash storages' peculiarities." — Preceding unsigned comment added by 2A01:2B0:3041:3020:21B7:43B:C3C5:C913 (talk) 16:49, 8 April 2014 (UTC)
- F2FS is still a file system intended to be used on flash-based devices with a built-in flash translation layer (FTL), and designed as such. I've clarified the article a bit so it's more clear, please check it out. — Dsimic (talk | contribs) 05:22, 9 April 2014 (UTC)
Separate page for Flash Translation Layer (FTL)
[edit]Flash file system is trying to solve at least two problems (TRIM and FTL) and is trying to benefit from random access (as opposite how classical hard drive works). So because of this, the inclusion of FTL (Flash Translation Layer) into this page seems like inadequate (because this is only one separate part of problem the page should explain). Also Flash Translation Layer has many aspects that are not related to Flash file system (implementation in firmware, specific bugs, hardware with/without FTL) which clould be (but does no have to be) solved by each one of Flash file system, so the page about Flash Translation Layer should have explanation that is not related to Flash file system. Because Flash Translation Layer has not own page, it has been moved around other pages in the past and this location is not perfect and will not be perfect until Flash Translation Layer will have own page. Also the separate page will make attention to others to expand it more deeply, and this may not happen if Flash Translation Layer is a part of other page which is focused on different kinds of eplanation (ie. this page do not need the Flash Translation Layer to be expanded like should be if on separate page). --Milan Kerslager (talk) 14:25, 17 December 2014 (UTC)
- Support: Makes sense, FTL is a related topic but not what the Flash file system article should cover directly. Using content from the Flash file system § Translation layers section to turn Flash translation layer into a separate article should be the way to go. Also, some history could be reused from the Flash file system § Origins section. — Dsimic (talk | contribs) 15:35, 20 December 2014 (UTC)
- Support: @Milan Keršláger: Please go for it, Wikipedia currently unnecessarily confuses FTL and flash file systems. -- intgr [talk] 09:04, 1 December 2015 (UTC)
- Support: 林博仁 (talk) 17:17, 16 March 2018 (UTC)
- Support. This is as true now as it was 4 years ago. --Bigpeteb (talk) 15:47, 19 March 2018 (UTC)
- Support. I came here looking for info about translation layers, not file-systems. 86.155.172.14 (talk) 13:37, 13 April 2018 (UTC)