Hi Junjiro, On Wed, Nov 30, 2011 at 11:52:03AM +0900, sf...@users.sourceforge.net wrote: > > Hello Kalus, > > Klaus Knopper: > > From my own experience, I was not able to kill an usual USB flash disk > > or SD card by "excessive" writes yet. I tried hard, really, even with > > the mount -o sync option. The german c't magazine has also run write > > tests over a year with millions of writes, and was not able to kill a > > single block. > > Just out of curiosity, how did you make your "writes"?
Various approaches, from just creating and deleting files over the file system layer with the partition mounted with sync flag in an endless loop, to dd on the raw device. Writing in sync mode and without buffers is extremely slow, so no matter which kind of test, file-based or device-based, I write only a few blocks at "the same location" (on OS side) to quickly reach the specified number of erase cycles. > It may be good to use direct-io for such tests, which makes buffer > cached disabled. Like in dd if=/dev/urandom of=/dev/sdb oflag=direct,sync bs=131072 ? You can add count=1 in order to overwrite only the first blocks, and count the repeats in a loop, so the test does not take forever until you reach the alleged write limit. A simple bash example, trying to destroy the first block of /dev/sdb containing the partition table and MBR by excessive writes: count=0 while true; do dd if=/dev/urandom of=/dev/sdb oflag=direct,sync bs=131072 count=1 2>/dev/null echo -n -e "\r $((count++))" done If partitioning /dev/sdb again would fail, after a sufficient number of writes to block zero, the destructive test was successful. Though I'm confident that the integrated controller will balance the writes amongst all physical blocks of the device on each write cycle, and block zero of /dev/sdb is not really the physical block zero on the NAND chips, I'd recommend not trying this with just your most expensive SSD. ;-) Of course I'm using aufs on Knoppix for keeping the file system layout handy without adding a lot of symlinks between read-only and read-write space, so installations and updates are possible where the base system is read-only. Just on embedded devices, I think that using aufs only for saving write cycles on the physical storage device is not the perfect way to go, especially when RAM and CPU power are tight. Regards -Klaus ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d
