SheevaPlug memory lifetime in production environment

[vorxio]

Hi,
We would like to use SheevaPlug with a monitoring application in the "real-world" (a java application that reads data through the USB and send it to a remote internet server).
The Sheeva is configured to use internal nand + ubuntu.
We have optimized (minimized) the number of writes of our application but we are still worried about the internal nand lifetime.

What are the "best practices" to minimize the operating system writes and increase the lifetime of the internal NAND? (disable system logs??? disable cron???)

Have you some experiences / tips of sheevaplug devices in production environments?

Thank you in advance,

  Vor.

[sfzhi]

The "best practice" is to make the root filesystem read-only. If the OS insists on writing something it should do that somewhere else. If there are no other storage devices available then use tmpfs.

[CqCn]

I am running from an external SDCard, in the SDCard slot.  I have done the following:
Almost all logs, cache, and tmp diretories are mounted on tmpfs.  For my server application, there is plenty of memory still left, so the majority of new files and writes being on the memory files, will reduce the hits on the flash.

Modern flashes have improved reliabillity, I read, that the life time issues are not as serious a problem as they used to be even a couple of years ago.

Since I run from the external SDCard, in the event the card shows signs of failing, I can easily replace the 4GB card, which is now selling for about $7 online.

I am considering one other final step. Even with very little writes or modifications to the flash (SDCard) files, the way the sytem is normally configured, there are atime and diratime access writes to the directories every time a file is just read, theses could be actual writes to the flash.

I am thinking of miounting the root /  as noatime,nodiratime.  I do not know for sure if this will cause any type of problems with normal operation, such as if some updates or housekeeping is based on the access time of files.

If anybody knows more about the noatime, for our ubuntu on the ShivaPlug, please post.
 

[restamp]

'noatime' simply inhibits the update of the inode's timestamp on access for ext* file systems.  It thus cuts down on the number of writes to the filesystem.  However, it does create some problems.  A common one is the inability to discern whether or not you have new mail.  (It tends to always look like you do.)  I use 'relatime', which allows an inode update if the current access time on a file is older than the current modification time.  This solves most of the timestamp problems, while still cutting down on file system writes, sometimes significantly.

FWIW, I've had a SheevaPlug that has been running 24/7 since Sept 2009 on an SDcard root file system.  Except for 'relatime', I've made no attempt to curb file system activity, and the SDcard continues to perform fine.  I really suspect the SDcards made today are quite capable of supporting an active Unix file system for an extended period without the risk of burn out.  I must confess, though, if I were using the SheevaPlug's internal NAND, I 'd probably be a bit more concerned about this, since it is not easily replaceable.

[CqCn]

'noatime' simply inhibits the update of the inode's timestamp on access for ext* file systems.  It thus cuts down on the number of writes to the filesystem.  However, it does create some problems.  A common one is the inability to discern whether or not you have new mail.  (It tends to always look like you do.)  I use 'relatime', which allows an inode update if the current access time on a file is older than the current modification time.  This solves most of the timestamp problems, while still cutting down on file system writes, sometimes significantly.

Thanks for that pointer.  I had just come across 'realtime', but have not really stopped fully understand it.  Also thought that realtime may not be avialble on the ext2 fs on our ShPlug ...

So let me see if I understand relatime correctly:  It does allow an access time update the first time a file is accessed after it has been modified, is that correct?  If so, in my server application, where most files are not modified, it is almost equivalent to noatime, but without the disadvantages you pointed out.  Great.

Since I now mount all the logs on tmps, I will lose the the logs on reboot, unless  do a save of the needed critical ones from a shutdown init.d/script. ...

[restamp]

Essentially correct for "relatime" (not "realtime").  See http://linux.koolsolutions.com/2009/01/30/installing-linux-on-usb-part-4-noatime-and-relatime-mount-options/

I use "relatime" on several ext2 file systems, root and otherwise.  It works for all ext type file systems.  Not sure about other fs types.

[sfzhi]

http://www.linux-mtd.infradead.org/faq/ubifs.html#L_atime

[CqCn]

Since I am remounting to get the relatime effect, and since it was already mounted atime, do I need to do noatime as well, as in

mount -o remount,noatime,relatime /

How does this diratime play into the previous discussion?  Should we, is there any down side, add nodiratime too?

[restamp]

If you specify both relatime and noatime, I'm not sure what will happen.  Perhaps the last one mentioned will take effect; perhaps the more stringent one (noatime) will.  My reading of the man page is that these parameters affect both files and directories.  The diratime and nodiratime parameters affect only directories, but not files.  (It's unclear whether "noatime,diratime" could be specified to update directories, but not files.  My guess is no.)

If this interests you, why not play around with these parameters and post the results.