Hi Jate, Since you are writing to memory, there should be no reason to do any write buffering (cache) on the ext2 filesystem. I wonder if running this following command will do what you want (disable cache)? /sbin/hdparm -W 0 /dev/mtdblockX 0
Dave Jate Sujjavanich wrote: > Ext3 requires a volume with at least 2048 blocks to create a journal. > > Ext2 is running very well on my nvram. I run a fsck on boot every time > which finishes in seconds. > > I am curious to know if anyone knows how to flush/commit the ext2 on a > reboot using a kernel notifier chain. I have something like this running > for my ide/CF device. > > - Jate > > -----Original Message----- > From: uclinux-dev-boun...@uclinux.org > [mailto:uclinux-dev-boun...@uclinux.org] On Behalf Of Dave Meador > Sent: Friday, December 19, 2008 2:49 PM > To: uClinux development list > Subject: Re: [uClinux-dev] Jffs2 on mtd on nvram slow > > Hi Jate, > > Jate Sujjavanich wrote: > >> Re: the ext2 fs. What sort of operations are you running? I am looking >> > > >> at putting a /var file system including logs. That's what made me look >> > > >> into journalling (do deal with power failures.) >> >> >> > For my application this partition stores project configuration and a > file with non-volatile variable values which are stored at rates of > about once a second. The file is used to load the last known values > back after a power cycle. > >> Do you run an fsck on the device during boot? >> >> > I don't run fsck at the moment, and I have had a few issues with fs > corruption when the system is shutdown abruptly. The filesystem being > so small, an fsck would not take very long (a few seconds). At some > point I was going to attempt using ext3 but just havent had the time > yet. Shouldn't be too difficult, just need to add the ext3 kernel > support and a mkfs.ext3 os support. > >> I seem to remember the minimum size for ext3 being 1024kB. This is why >> > > >> I picked jffs2. >> >> > I did a brief google search on a minimum size for ext3 and can't find > any info. I know that you can get an ext2 filesystem on there and then > you would have to account for the journal size if you try ext3. > JFFS2 is designed to run on flash devices and all the algorithms to > solve flash wear problems are superfluous when you attempt put it on a > non-flash device and perhaps this could explain part of the slowness > problem you are having. I am only suggesting an alternative method > which I have used and has good performance. I wish you good luck with > whichever method you choose. > >> - Jate >> >> -----Original Message----- >> From: uclinux-dev-boun...@uclinux.org >> [mailto:uclinux-dev-boun...@uclinux.org] On Behalf Of Dave Meador >> Sent: Thursday, December 18, 2008 7:52 PM >> To: uClinux development list >> Subject: Re: [uClinux-dev] Jffs2 on mtd on nvram slow >> >> Hi Jate, >> >> I have implemented a ext2 filesystem on nvram through MTD and phram or >> > > >> slram modules with 2MB of battery backed RAM. It is very fast and >> stable. And there was plenty of room remaining once implemented. I >> don't know how much extra space a etx3 filesystem will take but I >> think you should be able to get it working with 960K. The smaller the >> > > >> partition size, the less allocation table and journal overhead is >> necessary. >> I could be wrong here (someone please correct me if I am) but I am >> under the impression that JFFS2 is used on top of flash chips which >> require a sector erase cycle before write, whereas if your battery >> backed NVRAM is accessed just like a RAM, then you should be using >> either slram or phram kernel drivers and setup an MTD partition with >> the RAM address range you desire to map as a filesystem. I think this >> > > >> is the direction you should be going. >> Of course, you also need to initialize a filesystem on the >> /dev/mtdblockX partition once before the first use too. Then you can >> mount /dev/mtdblockX /some_mnt >> >> Hope that helps, >> Dave Meador >> >> >> Jate Sujjavanich wrote: >> >> >>> I'm running a 5235 @ 150MHz. I have created an MTD device on my >>> battery backed NVRAM. It has a 70ns cycle time. I've chosen a JFFS2 >>> file system to use with it. I cannot think of a journalling file >>> system that will fit in the 960k of space. >>> >>> I don't get very good performance on it. During a copy, the kernel >>> time ("sys" under top) hits ~100% for several seconds during a 336k >>> file. And the performance is pretty bad when syslogd is writing to >>> this file system. >>> >>> The contrast between the file system write and a raw write under >>> u-boot is pretty stark. Eraseall just flies. >>> >>> I can't figure out if I need to define read8, read16, and read32. The >>> > > >>> documentation for MTD is not too great. >>> >>> So the things I can think of are that might be going wrong are: >>> >>> 1. Misconfiguration of the MTD. >>> 2. JFFS2 is just slow >>> >>> Any thought? >>> >>> - Jate S. >>> > _______________________________________________ > uClinux-dev mailing list > uClinux-dev@uclinux.org > http://mailman.uclinux.org/mailman/listinfo/uclinux-dev > This message was resent by uclinux-dev@uclinux.org To unsubscribe see: > http://mailman.uclinux.org/mailman/options/uclinux-dev > > > > > > ************************************************************************ > ************ > This footnote confirms that this email message has been scanned by > PineApp Mail-SeCure for the presence of malicious code, vandals & > computer viruses. > ************************************************************************ > ************ > > > > _______________________________________________ > uClinux-dev mailing list > uClinux-dev@uclinux.org > http://mailman.uclinux.org/mailman/listinfo/uclinux-dev > This message was resent by uclinux-dev@uclinux.org > To unsubscribe see: > http://mailman.uclinux.org/mailman/options/uclinux-dev > _______________________________________________ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
