On Thu, Jan 03, 2014 at 19:07, Theodore Ts'o [mailto:tytso@xxxxxxx] wrote: > > On Fri, Jan 03, 2014 at 11:54:12AM -0600, Eric Sandeen wrote: > > > > > > This call chain only happens if the block device is mounted. > > > > Sure, but I thought that's what they were doing. Maybe I misread. > > > > I thought this was in relation to doing what they called a "barrier > test", where you are writing to flash device and then drop power, and > then see if the CACHE FLUSH request was actually honored. (And > whether or not the FTL got corrupted so badly that the device brick's > itself, as does happen for some of the crappier cheap flash out > there.) > > But I'm not sure precisely how they implemented their test. It's > possible it was done with the file system mounted. My suggestion was > to make sure that the flash was proof against power drops by doing > this using a raw block device, to remove the variable of the file > system. > Just as a quick reply for today: If I remember right, Weller has done the barrier test w/o file system mounted. Weller can give more details when he is back in office. However, these tests were done some while ago with another type of eMMC. > Given that they've since reported that they can repro the problem > using soft resets, it doesn't sound like the problem is related to > flash devices not handling powe drops correctly I think so as well, for the same reason and also because our tests with journal_checksum show the same problem w/o any checksum error. > --- although given > that I'm still getting reports of people who have had their SD card > get completely bricked after a power drop event, it's unfortunately > not a solved problem by the flash manufacturers yet.... or rather, > the few (many?) bad apples give all low-end flash a bad name. > > - Ted Mit freundlichen Grüßen / Best regards Dirk Juergens Robert Bosch Car Multimedia GmbH -- 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
