For the NOR flash, when the write( , , 1) routine is called, the file system(jffs2 in this case) has to read back the whole sector, modify that byte, erase the sector and then write back the whole sector (in order to write a single byte). Is it not so..So it does affect the flash-lifetime right?
- Prasad On Mon, Oct 19, 2009 at 5:04 PM, Erwin Authried <ea...@softsys.co.at> wrote: > for NOR flash, the number of erase cycles on each sector is limited, not > the number of writes. For the flash lifetime, it doesn't make a > difference if you write one byte at a time or a complete sector at once. > > -Erwin > > Am Montag, den 19.10.2009, 16:43 -0700 schrieb Prasad: >> Interesting..till now i was thinking there is still some kind of >> buffering mechanism in case of NOR flash. So if there is a process >> that opens a file writes one byte at a time (write() or fwrite() on >> jffs2 partitioned file system), this will kind of wear out the flash >> pretty right?. May be a stupid question, can we force the buffering >> even for NOR flash for increasing the longevity of the flash ? >> >> - Prasad >> >> On Mon, Oct 19, 2009 at 12:49 PM, Keith Mund (AZ) <keithm...@cox.net> wrote: >> >>from Prasad - Monday, October 19, 2009 10:53 AM: >> >>I mean to ask, is there any advantage in using NOR-ECC flash agains >> >>regular NOR flash. Does the linux mtd driver/jffs2 differentiate it? >> > >> > The "advantage" part depends on the needs of each system. Some benefits of >> > ECC are that it helps overcome problems with occasional false flash reads, >> > and buffered writing can be faster. Direct write through with NOR >> > dramatically reduces the chances of corruption due to an interrupted write. >> > >> > Linux does determine if you have NOR-ECC and enables buffering. Buffering >> > is >> > a must because you can call the file write function numerous times, even to >> > write one byte at a time. NOR-ECC only allows one write per page before an >> > erase so the writes are buffered before they are committed. >> > >> > Keith Mund >> > >> > >> > _______________________________________________ >> > 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 > > _______________________________________________ > 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
