Lots of apps and daemons write files you may not even be aware of. Any
of this can
cause problems since they all require flash writes.
You can, of course, mount the file system read only - that works.
And as others have mentioned, create a small partition for your data
collection.
One thing I've done that works well to eliminate a bunch of these flash
thrashing files,
is to use 'find -newer'
Boot your board and let it run normally for awhile, make sure the RTC is
set correctly.
Then do a shutdown and reboot. Create a file that has a creation date a
little before the
last boot time.
Then use the -newer option with find - it will give you a list of all
the files touched or created
during or after the last boot. You will probably find pid files, log
files, error files, that you didn't know
about. Most of these can be remapped by options of the offending daemon.
Create a ram disk partition. Configure all the stuff that creates them
so they are created in the ram disk.
The ones you cannot easily remap, set up a symbolic link from flash to
the ram disk.
This will allow you to run your root file system R/W and still avoid
writing to it.
You should be able to make your file system bullet proof.
I've got stuff running in the field that can be reset any random time
and it always comes up.
Just make sure to use a journaling file system for the partition you
plan to use for writing
your own logs.
Larry
On 11/22/2013 6:54 PM, Don Tucker wrote:
> Maybe overkill for your application, but in case you haven't seen it:
>
> http://www.embeddedarm.com/about/resource.php?item=466
>
> I've implemented unionfs on a TS-7260 with the 2.6.21 kernel. I had to
> play around with my partitions on the SD card and mod linuxrc-sdroot,
> but I was able to get it to work. I can provide you with specifics, if
> you decide to go that route.
>
> Don
>
> On 11/22/2013 5:09 PM, Joseph Bouchard wrote:
>>
>>
>> On 11/22/2013 12:41 PM, Clark Dunson wrote:
>>> Hi everybody;
>>>
>>> We use a TS-7260 with 2.6.21, SDBoot, read-only root, and read-write
>>> /var. We have about 160 earthquake sites throughout the world and
>>> remotely administer them from our central offices. We've been having
>>> kernels remount /var as read-only more frequently these days, and
>>> are looking for a better way to handle it, so ask the experts! Thank
>>> you.
>>
>> I'm guessing you are getting corruption when someone unplugs the
>> power, then plugs in back in? I have had problems with that. What
>> about your setup has you mounting /var as read/write? Is that so the
>> O/S can write little pid files, etc, or are you writing your
>> earthquake data to /var? I have systems where the whole filesystem is
>> read only, then a tiny ram disk for /tmp/ and /var/tmp. That works
>> very well.
>>
>> If you are writing data to it, I suggest keeping the card mounted R/O
>> most of the time, then when you have data to write go through a cycle
>> of:
>> - fsck, -y /dev/whatever/is/your/var
>> - mount /var -o remount,rw
>> - write data
>> - sync
>> - mount /var -o remount,ro
>>
>> That keeps your filesystem clean. In the rare case where you lose
>> power right in the middle of that write cycle (call that "one in a
>> thousand", the next fsck will hopefully clean it up. Then actual
>> corruption should be "one in a million".
>>
>> Just my 2 cents worth.
>>
>> Joe
>>
>
>
--
Larry Eaton
http://www.rnmicrosystems.com/
------------------------------------
Yahoo Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/ts-7000/
<*> Your email settings:
Individual Email | Traditional
<*> To change settings online go to:
http://groups.yahoo.com/group/ts-7000/join
(Yahoo! ID required)
<*> To change settings via email:
<*> To unsubscribe from this group, send an email to:
<*> Your use of Yahoo Groups is subject to:
http://info.yahoo.com/legal/us/yahoo/utos/terms/
|