How to create a writable mount point??

[MClement]

How can we create a persistent, writable folder on the PPMAC to save some variables? We want them to be saved through power cycle and written to frequently.

 

We don't want to expose the OS to rewritable.

We want to use space somewhere on the internal memory (no USB,CF)

 

We have it working with a mounted cifs share but now want to move it to local to PPMAC.

 

Thoughts?

[shansen]

MClement:

 

We have traditionally kept our persistent data in a folder under /var (/opt works too, but the Power PMAC data is stored there by default). The only caveat is that /var is not persistent, so we have to sync the filesystem whenever a change is made.

 

You can create a folder in a persistent location (say /bin or /opt), but if the Power PMAC crashes while that location is being written to it can cause disk corruption. The sync method I described previously gets around that issue.

 

How frequently do you need to make changes? Could you buffer the changes and write to disk in a slower background thread? If you buffer the changes, you could mount /.readonly/ as read/write and copy the data directly to persistent memory every time you need to make a change.

[MClement]

And how are you doing the sync?

 

We definitely want it to persist. We are writing to it maybe once every handful of seconds.

[shansen]

Here is a bash script that shows how to sync the 3 main non-persistent mount points (/var, /etc, and /root):

 

#!/bin/bash
# Synchronizes /var, /etc, and /root

echo "Starting sync."
echo "Mounting file system as read/write"
mount -o remount,rw /

#
# Copy /var to persistent memory
#
cd /.readonly/var-tmpfs-mirror/
echo "Copying new files from /var."
cp -a * ../var &> /dev/null

#
# Copy /root to persistent memory
#
cd /.readonly/root-tmpfs-mirror/
echo "Copying new files from /root."
cp -a * ../root &> /dev/null

#
# Copy /etc to persistent memory
#
cd /.readonly/etc-tmpfs-mirror/
echo "Copying new files from /etc."
cp -a * ../etc &> /dev/null

#
# Sync to disk
#
echo "Syncing file system."
sync

echo "Mounting file system as read only."
mount -o remount,ro /
echo "Sync completed."

 

This script should be placed in /bin so it is persistent. Also make sure the script has full permissions (chmod 777 /bin/).

 

From what you have described, it sounds like the best procedure is for your background thread to write constantly to . Then every (10 seconds, 1 minute, 10 minutes?) issue this bash script to save all of the written data to disk. If you use the script above, you probably should remove the copy logic for the locations you aren't using (if your folder is in /var/, there is no need to copy files and sync from the other locations).

 

One problem you are going to run into is that the Power PMAC has a default setting that prompts you to check the filesystem after the drive has been mounted/umounted a certain number of times. You will start getting an "unchecked filesystem" message every time you mount/unmount. To disable this message, issue the following command from a Linux terminal:

 

tune2fs -c 0 /dev/

 

To find , you can check the startup log:

 

dmesg | grep root=/dev
Kernel command line: root=/dev/sda2 ro rootdelay=8 rootfstype=ext2 console=ttyS0,115200

 

In the above case, my drive was /dev/sda2.

 

The only thing I'm not sure about here is the viability of constantly mounting/unmounting. It may be better to leave the folder mounted as read/write, but this could cause disk corruption issues if the Power PMAC looses power while you are writing to disk. Also, flash memory has a limited lifetime in terms of write cycles, so doing continuous writes may not be the best solution.

 

Perhaps someone from DT could weigh in on these issues?

[MClement]

I had not thought of the limited write issue. That brings up a good point that maybe writing to the share as we were doing IS the better way? We have seen issues when the share is not up that cause the write to fail and data loss. Maybe the answer is just to better error trap the share write.

 

It's a shame because the data we want to save is only consumed by the ppmac and so made sense to move it to the ppmac for storage/updating.

 

Wonder what DT's response is to saving data frequently on the ppmac and how they suggest doing it.

[shansen]

Is there any particular reason you don't want to use an SD card or a USB stick? That seems like it may solve both issues (limited writes + file system corruption).

[MClement]

it very well may be the best approach. We cringe at the idea of having to replace a customers SDcard every few years, but that's better than the flash on their ppmac.

[shansen]

How about one of these?

 

http://www.amazon.com/SanDisk-Cruzer-Low-Profile-Drive--SDCZ33-016G-B35/dp/B005FYNSZA/ref=sr_1_1?ie=UTF8&qid=1404414404&sr=8-1&keywords=small+usb+drive

 

It is very small and fits right in the front of a Power PMAC without sticking out too far. They will also last longer than an SD card (but that depends on how often you write to it).

[MClement]

why do you say it will last longer? They both should be using flash and have wear leveling right?

[shansen]

Many cheap SD cards use notoriously poor quality flash. If you buy a high quality SD card, then you are probably correct that there isn't any difference.

[Omron Forums Support]

MClement,

 

I have some sample code of how to write quickly to PMAC's flash memory in C, which will be retained between power cycles. Note though that this will reduce the lifetime of the flash.

 

I also have example code of writing to SD cards/flash drives through C.

 

If you are interested, send an email to support at deltatau dot com ATTN Charles and I'll send you those.

[MClement]

Thanks Charles but we whipped something up to test those as well.

 

We ended up not wanting to replace the PPMAC or the SDCard so we went back the share but added error trapping and self healing code to make it robust. The share will not need replaced over time so it really was the best option.

[KEJR]

I realize that I am late to this thread, but wanted to comment that I am saving data to the SDcard [nearly] every second.

 

I have a thread that scans the memory that I want to persist (non volatile P vars in my case) and if there is a difference from the last time I saved it dumps the data to disk. I have some number of P vars that get saved (I believe 1000 p vars). I wrote all of this code in a C thread doing the file access directly through C api's.

 

I bought the biggest SDcard I could at the time and made sure it had wear leveling. With my "only write on change of state" algorithm and the wear leveling I figure I have a liftetime capacity on this flash.

 

The algorithm works nice because if someone stops the machine and goes to lunch (or leaves it on for the weekend) the thing isn't sitting there churning out data continuously to the disk. I save my data in two files in case one gets corrupted and keep a 32 bit CRC in them that I compare at startup.

 

Oh the lengths we go to to abuse new technology (in the past we used a 4K or so battery backed SRAM chip!!)

 

:o)

[ulhasfegade]

MClement,

 

I have some sample code of how to write quickly to PMAC's flash memory in C, which will be retained between power cycles. Note though that this will reduce the lifetime of the flash.

 

I also have example code of writing to SD cards/flash drives through C.

 

If you are interested, send an email to support at deltatau dot com ATTN Charles and I'll send you those.

 

Dear Mr/ Charles

 

We are using power clipper and want to save data on SD card. Please send me example code for this

[steve.milici]

Please contact support@deltatau.com for this request.

[Clopedandle]

The examples you seek are in the Application Note titled "Saving Files on Power PMAC or External Media". It's available under FileDepot-->Power PMAC-->Application Notes. I strongly suggest you use KEJR's approach of limiting how often you write to the device in order to limit wear.