SDcards and NAND memory

[CqCn]

Moderator's Note:  This is a continuation of a discussion that began here and evolved into the current topic.

Frankly, I prefer to specify the device by it's /dev name.  (My bootargs_root is "root=/dev/mmcblk0p1 rw,relatime")

Thanks for your thanks.  Glad you got your Plug back up and operating.

restamp, Thanks you for the tips!  I would change mine to the /dev/ format too; I was just getting used to and memorizing all the new devices...
BTW, you are running 'realtime' even with a flash?  Unless you have one of those very large >8GB ones, which gets used sparsely, and one of the very recently made ones (the technology is improving here) the life would be affected by repeated writes.  Yes, they are cheap to replace, but at some point they become unreliable before you notice serious problems.  I am sticking with noatime.

[restamp]

When I got my Plug, NAND technology was new to me, and I had to read up on it.  One of the reasons I quickly moved to an SDcard was that I wanted to experiment w/o any fear that something I might inadvertently do would ruin the NAND memory on my Plug.  An SDcard, as you say, is replaceable, but the on-board NAND is not.

I don't hit my SDcard very hard - at least not yet.  So far it has held up well.  I know that rewriting inode access times is intensive, but for some things, like mail files, it is desirable to know whether they have been read since being written, i.e., whether you have new mail or not.  That's why I settled on "relatime" rather than "noatime" - it alleviates most of the writes w/o actually breaking programs.  (It would be nice if the ext[23] fs's allowed you to set this feature on a per-file basis, wouldn't it?)  And, BTW, I create all my SDcard file systems as ext2, not ext3.  I suspect this probably has more of an impact on minimizing the number of writes than "relatime" vs. "noatime".

BTW, I'm not sure if specifying "relatime" or "noatime" on the Uboot parameter really works.  I also specify it in my /etc/fstab.  Between specifying it both places, I figure it will be honored.

The subject of wear leveling is a complex one.  For a good primer, see:  http://www.storagesearch.com/siliconsys-art1.html

Frankly, I don't understand how any SDcard can get by without a static wear leveling algorithm.  With a jffs2 FS over raw NAND, the information about which blocks are free (and therefore available to take part in the wear leveling) is available, but on an SDcard, the NAND blocks are internally mapped to conventional 512-byte blocks and the card has no way of knowing which of these are free and which are not.  Thus, the card must treat all blocks as potentially containing valuable data (right?), and either it must have a fairly large excess of physical NAND memory to serve as its free pool (which would be expensive), or it must use static wear leveling (again, right?).  (If anyone can shed more light on this, please do so.  Also, if anyone knows if there is some way to cause the card to read out the stats on its internal data on block write counts, etc, I'd love to hear about this.)

FWIW, I am using the following card:  http://www.microcenter.com/single_product_results.phtml?product_id=0304661

I bought this card because a friend tried it and said it works well with the Plug.  Empirically, it appears my Plug issues a write to the SDcard about once every 45 seconds on average, so statistically, the card should last a while.  As it turns out, 16GB is wretched excess for me, but in today's world real-estate is cheap.  And, so far, so good, although, I hesitate to add, my friend's card just recently failed.  But, it's warranted for 3 years, so we'll see how it goes.

[CqCn]

restamp,
Perhaps we need to move this discussion to another thread.  I will reply in a new one, when I get back home later today.

BTW,  how do you change the next boot device from the current running os, without opening the serial console? Is there a way for that in the new boot?

[restamp]

Good idea CqCn.  And a perfect chance to figure out how to do such things in a Simple Machines forum!

To respond to your question, I don't know.  The obvious way is to do it through the Uboot.  It's theoretically possible to do this from Linux, if you give Linux access to the Uboot environment section of the NAND, but the only tools I know to manipulate this are the fw_printenv and fw_setenv executables that came with the alpha-6 installer.  These particular executables are Intel-based, but I suspect if you had the sources you could build them for the Plug.

What would really be nice is a program like the eeprom program found on Solaris.

[CqCn]

restamp,  Sorry, it took a few days for me to get back to this thread.  Yes, I understand the problems of using noatime with some modified time dependent utils lik mail.

The SDCards I have been using are 2GB, 4GB sizes.  I happen to have a few of these around.  I have a couple of MicroCenter, Kingston, and one Partist (just started).  At your 16G size it is definitely a newer chip.  The newer chips, in general, are more reliable for repeat writing.

From what I understand, the newer ones may also have the distribution algorithm built into the chip.  The external interface does not see this, but internally it get redistributed on subsequent writes to a new physical sector.  Do not know the details of how this is affected on a reformat or things like that.

I have been using flash for many things for a while, and have been keeping an eye on life.  I have had small 1MB cards becoming quite unreliable after a year plus of intensive use, while close to full.  After reformat, the available sectors became less by about 5%, indicating permanent failures similar to those of long term use of hard disks.  After the reformat, this particular stick, worked quite reliably.  The type of use you are talking about probably will last 2+ years without trouble,  just a guess.

There is a commercial software that can be added, supposedly working with many os, that would transparently redistribute the write;  they claimed it increased the performance significantly.  They were trying to get the software to be incorporated by the chip makers, but had a retrofitable version even for smaller sticks ~4GB.  They were going to license the sw on a per stick basis.  When I find that product, I would report here.

If I want to run any write intensive applications such as repeated compiling, or servers where data is constantly getting modified such as mail servers, I personally would go to a usb hard disk; I am limiting flash to where it wont cause a problem in the noatime mode.

[DamonHD]

Coming rather late to this, but maybe I can add a data point or two.

Currently my main Internet-facing server boots from a 4GB SD card and keeps bulk data on a conventional hard disc which is spun down most of the time with laptop mode.

http://www.earth.org.uk/low-power-laptop.html

I have noatime on the SS and magnetic media, and laptop-mode's commit=600 further reduces traffic.

I've then made an effort to trim unnecessary logging and so on.

I'm using ext3 for all the filesystems though received wisdom suggests that ext2 would generate less traffic still.

In any case, I can tell you that it's been running for a couple of years without any obvious problems so far.

I won't run laptop mode but I will make use of the other techniques.

Rgds

Damon