sean machin wrote:
> guywatelle wrote:
>
>>
>>
>> --- In <ts-7000%40yahoogroups.com>,
>> Samuel M Smith <> wrote:
>>
>>> I have had problems with file system corruption on a 7400 rooting from
>>> the SD Card.
>>> Although there was some useful information in a prior thread, ( SD
>>> card corruption 09 March 2008)
>>> it didn't address my problem specifically. I would appreciate some
>>> suggestions on how to reliably use the SD Card given
>>> inadvertent power cycles.
>>>
>>> My configration is a 7400 using debian sarge 2.4 kernel, standard
>>> Technologic SD image distribution.
>>> uses the linuxrc-sdroot script to root from the sd card and mounted
>>> fstab
>>> /dev/sdcard0/disc0/part3 / ext2
>>> defaults,noatime,async 1 1
>>>
>>>
>>> The specific problem is that whenever the 7400 is powered off without
>>> running shutdown, on the next bootup
>>> fsck shows errors. Usually fsck is able to fix all the errors.
>>>
>>> The problem occurs when the unit is not allowed to complete fsck
>>> before being powered off again. That is if it
>>> gets powered off during fsck of the root on SD card then it could be
>>> non-recoverable.
>>>
>>> Since the 7400 is part of a larger system, I have no control over when
>>> or how fast the larger system is
>>> powered on or off. During testing or setup of other parts of the
>>> system, the 7400 might get repeated power cycles within a few seconds
>>> of each other
>>> which is not enough time for fsck to complete.
>>>
>>> In prototype testing, I have twice had the SD card get unrecoverably
>>> corrupted, ( fsck can't fix it automatically) so the 7400 does not boot.
>>> I have had to re flash the sd card. These are new sd cards.
>>>
>>> It seems to me that I need to disable the automatic fsck on bootup.
>>> But if I do that, I am concerned about the long
>>> term reliability of the file system on the sd card?
>>>
>>> In the previous post, teadapt was using the ext3 journaling file
>>> system. Apparently I can convert an ext2 to ext3 easily using fstune
>>> but I don't think ext3 is supported in the standard TS kernel for the
>>> 7400.
>>> Is JFS?
>>>
>>> I am new to using Linux in an embedded system. I have used VXWorks and
>>> NetOS where the OS is in NOR flash and doesn't get corrupted
>>> by inadvertent power cycles.
>>>
>>> The selection of the 7400 was based on having the resources provided
>>> by a full debian distribution (not TSLinxu). So if
>>> I can't reliably boot from SD Card given inadvertent power cycles,
>>> then its not a viable platform for me.
>>>
>>> What sort of corruption will creep in if I don't fun fsck every time
>>> it boots?
>>> What is the best practice for managing fs corruption with embedded
>>> linux given inadvertent power cycles?
>>>
>>> My application only needs to write to disk for logging. Right now I
>>> have a single 1GB SD card with OS and application files on the same
>>> partition, but
>>> I could put my application log files on a separate partition. But
>>> there are still some system logs that I would like to have (at least
>>> during testing).
>>>
>>> I want my application logs to survive a power cycle so using a ramfs
>>> as someone suggested won't work but my log rate is slow and disk
>>> performance
>>> is not an issue so I don't think the extra load of using a journaling
>>> file system is a problem.
>>>
>>> So it seems to me that I need to turn off automatic fsck and use a
>>> journaling file system. Suggestions?
>>>
>>> I read in Ward's "How Linux Works", however, that the kernel won't
>>> mount an ext3 file system if the journal is non-empty which could
>>> happen on an inadvertent power cycle. One has to first run e2fsk -fy
>>> to flush the journal. So it seems that I would still be susceptible to
>>> having the system not boot after
>>> an inadvertent power cycle if I use ext3 and turn off automatic fsk on
>>> bootup. Is this true?
>>>
>>>
>> **************************************************************************************************
>>
>>> Samuel M. Smith Ph.D.
>>> Founder
>>> ProSapien LLC
>>> 2966 Fort Hill Road, Eagle Mountain Utah 84005-4108 USA
>>> 1.801.766.3527 x112 (voice) 1.801.766.3528 (fax)
>>> mailto: (email)
>>> http://www.prosapien.com/ <http://www.prosapien.com/> (web)
>>>
>>>
>> I know it is far too late to answer this mail but maybe it can help
>> other people.
>>
>> I face the same problem with a 7350 board and here is how I manage the
>> problem.
>>
>> I use the fastboot script on boot up. Fastboot mount partition 4 as
>> read only, so it is protedted against data corruption. I put all the
>> config file and read only data on the partition 4. For the data that I
>> need to write, I convert my partition 1 to a ext3 file system. I
>> enable the filesystem check on every mount (tune2fs -c1 -j
>> /dev/tssdcarda1). I mount this partition on /mnt/data and I write all
>> data on that directory.
>>
>> I made more the 2000 power cycle and every thing stay in place. I use
>> Kodak SD card somebody tell me that he have problem with cheap SD Card
>> but it was not a technlogic systems board.
>>
>> The only problem i found with this setup it is that it take a long
>> time before the data is committed on the SD card (approx 5Sec) in my
>> case it is not a problem.
>>
>> I hope it help somebody!
>>
>>
>
>
>
>
>> __,_
>>
> You guys may also want to look at industrial specced SD cards that are
> designed to reliably handle
> a hard shutdown, e.g. http://www.stec-inc.com/products/SDcard/. I
> believe (but have not actually
> tested myself), that these cards contain special hardware to prevent
> corruption on power down.
> Should be worth looking into if you're having corruption on power down
> problems.
>
> Let me know if you do use them and how they work out for you too?
>
I don't think they'll solve file-system corruption problems - they
should, however, solve flash block corruption problems; and random
writes that may occur on a failing power supply and an NAND flash.
If your application does not require full file-system semantics, it
might be worth considering writing data directly to a SD partition,
without using a file system. (e.g. fopen("/dev/sd0") ) Because the sd
card appears as a block-device, you could simply write a block of data
followed by a checksum. The checksum validates that the block is
legit. At app startup, you just scan forward until you find the first
zero (or corrupt) block, and continue writing log data from there.
If you require more complex semantics you may be better off with a full
file-system; but then you need to solve the shutdown issues. Maybe a
storage cap and a diode attached to a GPIO to indicate power failure?
-Brett
------------------------------------
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://docs.yahoo.com/info/terms/
|