Talk:How to Damage a FLASH Storage Device
Flash storage-specific file systems
Striking that the article has no mention of a flash storage-specific file system. I would have thought that a primary recommendation is to use UBIFS rather than FAT or ext3. Regards, ... Peasthope 16:10, 13 March 2013 (UTC)
Refer here. UBIFS_on_XO ... Peasthope 14:00, 29 March 2013 (UTC)
- Thanks. UBIFS is appropriate for raw flash, and that's how we tried it, but it did not meet our requirements and we have returned to JFFS2. In contrast, the article for this talk page is about managed flash, which is a different problem. UBIFS would not be used on a removable flash storage device, because it is not supported by other operating systems. It could not be recommended. I don't see how UBIFS is relevant to managed flash, so I have removed it from the article. --Quozl 23:15, 28 July 2013 (UTC)
A Simple Algorithm for a Non-expert User to Format a Flash Store ...
... based upon upper bounds for unpublished parameters of the device. This is a draft proposal.
Mitch Bradley wrote, "If you can, stick with the factory map".
There are two cases where the factory map will be lost. A naive user can reformat before encountering this advice. Reformatting again with better strategy might then recover better performance and a longer lifespan. Secondly, the directory of a flash store can fail catastrophically so that the choices are to stop using the store or to reformat it. The majority of users will not have flashbench available and will not have detailed knowledge of partition and filesystem structures. In such cases a simple algorithm for reformatting seems preferable to discarding the device or to reformatting blindly.
The article written by Arnd Bergmann provides a valuable background. https://lwn.net/Articles/428584/
Based upon the capacity of a store, these upper bounds on the size of "write page", "erase block" and "erase segment" are assumed. The table is from http://lists.laptop.org/pipermail/devel/2011-March/031505.html with additional information.
| Capacity, MB | Upper bound on size of write page, WPUB | Upper bound on size of erase block, EBUB | Upper bound on size of erase segment, ESUB |
|---|---|---|---|
| 256 MB | 1 KiB | 64 KiB | 64 KiB |
| 512 MB | 2 KiB | 256 KiB | 256 KiB |
| 1 GB | 4 KiB | 512 KiB | 512 KiB |
| 2 GB | 4 KiB | 512 KiB | 512 KiB |
| 4 GB | 8 KiB | 1 MiB | 2 MiB |
| 8 GB | 16 KiB | 4 MiB | 4 MiB |
| 16 GB | ?? KiB | ?? MiB | ?? MiB |
| 32 GB | ?? KiB | ?? MiB | ?? MiB |
| 64 GB | ?? KiB | ?? MiB | ?? MiB |
| 128 GB | ?? KiB | ?? MiB | ?? MiB |
Locate your flash store in the preceeding table.
Partitioning for any filesystem.
- Leave the first ESUB unallocated. The partition map and signature will be there.
- Begin the first part at the second ESUB. Each part should be a whole number of ESUBs.
With a capacity of 512 MB for example, the first part should begin at 256 KiB. If fdisk refers to "logical sectors" of 512 bytes, the first part will begin at the 513th sector and will occupy n x 512 sectors, n being a whole number.
- To maintain alignment of erase segment boundaries and partitions, each subsequent part should occupy a whole number of ESUBs.
Formatting a Partition for FAT.
- To avoid splitting write pages in block writes, the filesystem logical sector should be a whole number x WPUB.
In the 512 MB CF for example, WPUB is 2 KiB. This command will make logical sectors of 2 KiB with 1 sector per cluster. The root directory is specified to contain 512 entries.
mkfs.vfat -F 16 -n MyPart -r 1536 -s 1 -S 2048 -v /dev/sdb1
FAT size, cluster size and root directory need more attention but I want to know whether the idea is workable.
Regards, ... Peter E., Peasthope 01:45, 27 July 2013 (UTC)