On Thu, Oct 10, 2013 at 08:28:20AM +0000, Prasanna NAVARATNA wrote: > > I'm using Hynix eMMC4.41 with Linux kernel 3.4.5. > > After mounting ext4 partition /userdata with 'discard' mount option enabled, > fs triggers TRIM commands to eMMC after every file deletion. With this > setup, for a continuous reboot test (5s awake and issue reboot and repeat) > with 10 or 20 iterations, i see data corruption in eMMC consistently. > > mount options are :- noatime,nosuid,nodev,noauto_da_alloc,discard > encryptable="path" > > What am i missing here? if 'discard' mount option is removed, then no data > corruption in eMMC for more than 200 iterations. Does TRIM needs some extra > care? BKOPS is not enabled in eMMC (is bkops mandatory if using TRIM?) > Are there any latest patches which address these corruption issues during > reboot with discard option enabled? Unfortunately, there is a lot of what professionals in the field call "crappy flash" out there. This is especially true of low-cost flash devices, such as eMMC or SD cards. (Heck, there are cards marketing as containing 16GB of data that only contains 8GB of space, and rely on the fact that many people never completely fill their SD cards, because when you write over 8GB, data starts getting lost or corrupted.) If using the TRIM command on the eMMC device results in corruption, then the card is broken by definition. It may be that using using fstrim instead of the discard mount option will work better for you; with fstrim, which is either run manually or periodically by the user, the Kernel will issue trim commands for all of the unused regions of the disk when the fstrim program is run, instead of after every delete. The fstrim approach often results in better performance (especially on low-end flash) than issuing a discard after every file deletion, which is why I recommend it. However, if the hardware is so broken as to result in file corruption with the discard option, there is no guarantee that it might not also result in file corruption when using the fstrim approach --- it might just not be as obvious, so you don't catch it in testing, but only catch it production. Unfortunately, many product managers (especially for low-end embedded/consumer devices) are more concerned with saving a penny or two on the Bill of Materials cost of their embedded devices than they are about the safety of their users' data. And so the eMMC manufacturers have responded to this market demand by cutting corners and making craptastic flash devices. Isn't the free market system wonderful? You may also find that some of these devices have very atrocious 4k random write speeds, and in fact if you try to use them as part of a general Linux system, as opposed to storing digital images on a FAT file system, that simple heavy use will result in horrible performance, or worse, data corruption. Hopefully with the higher end mobile handset / consumer devices, the manufacturer, who will be buying eMMC devices in lots of several million units at a time, will be carrying out their own quality control and testing. But if you are buying just a few units at a time aas an individual hobbyist/consumer, life is very tough.... Regards, - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
