My message will be creating a little mess on mailing list, I can't response directly on mail-archive or nabble web interface to Steve Costaras, so I will quote here and send it.
<quote steve> For flash devices you really want to use a non-journaled and COW type file system. You'll end up killing your flash drive which would be far worse. For embedded you may want to look at jffs2; logfs; and similar. If you don't have those in your kernel, ext2 would also be much better due to it's lack of journaling though it is not as good as the others above for flash. </quote> I have seen some information about that file systems but is information on web [1] that I can't use it on sd card because of controller inside it. <quote steve> that being said, as Dave mentioned it shouldn't cause a file system failure (would be a device failure in which case you'd probably know it ;) ). <quote> Sorry by the off-topic On Thu, Jul 8, 2010 at 5:13 PM, Aníbal <[email protected]> wrote: > On Thu, Jul 8, 2010 at 4:21 PM, Dave Kleikamp <[email protected]> > wrote: >> On Tue, 2010-07-06 at 17:45 +0100, Aníbal wrote: >>> Hi, >>> >>> I am working on a embedded device, that have proprietary >>> implementation of the driver to talk with sd card, it's use linux >>> 2.6.21 and it includes the jfs utils 1.1.11. >> >> 2.6.21 is a rather old kernel, but I don't know of any fixes that went >> into jfs since then that might explain this problem. Typically, >> journaled file systems aren't recommended for sd cards. That's not a >> reason that jfs shouldn't function correctly though. It's just that the >> journal blocks are written to frequently, which isn't really good for >> sd. > > I am using a journaled file system to prevent file system corrupt when > occurs a power failure. > >> >>> It has some partitions on a 2 gb card, two are read and write that are >>> retrieving the errors. The image of linux is writhed using dd_rescue. >>> The problem is is that files disappear, files have contents from >>> others files and we have seen one partition that simple vanish. >>> >>> When errors occur Is normal having messages on dmesg like this : >>> >>> ERROR: (device tssdcarda6): DT_GETPAGE: dtree page corrupt >>> ERROR: (device tssdcarda5): diRead: i_ino != di_number >>> >>> On the last occurrence the output of the fsck contained a lot of >>> errors, the content is at the end of email. >>> >>> Anyone have seen a behavior like this ? >> >>> The device is remote, It isn't easy to reproduce on desk and log files >>> aren't a good way to get info. >>> >>> I want to find a way to try reproduce the error in a more predictively >>> way, I was thinking on use the jfs test case that are described on >>> documentation that as with sources, but I don't have found it. Can >>> someone point to me ? >> >> Have you tried other file systems besides jfs? If you see problems with >> other filesystems, the problem is probably not in the file system. > > I have tried ext3, that return the error off trying to access beyond > limits of partition, this message appears on dmesg. > >> >>> Regards, >>> Aníbal >>> >>> Output of fsck: >>> >>> r...@smartgate:/# fsck.jfs -ndvv /dev/tssdcarda6 >>> fsck.jfs version 1.1.11, 05-Jun-2006 >>> processing started: 7/5/2010 21.15.40 >>> Filesystem is currently mounted. [xchkdsk.c:1477] >>> WARNING: Checking a mounted filesystem does not produce dependable >>> results. [xchkdsk.c:1478] >> >> The above warning is legitimate. Running fsck against a mounted >> filesystem will not see a consistent file system. Not all of the errors >> reported may be real. >> -- >> Dave Kleikamp >> IBM Linux Technology Center >> >> > ------------------------------------------------------------------------------ This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first _______________________________________________ Jfs-discussion mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/jfs-discussion
