I know what a write-back buffer is... But I would never characterize a filesystem's write throughput as the peak bandwidth when writing into the buffer. (That's a marketing trick.)
Extended writes either fill up memory or degrade to a number which is more reasonable to compare to the write bandwidth of JFFS2. wad On Dec 17, 2007, at 3:06 AM, Artem Bityutskiy wrote: > Joel Stanley wrote: >> It makes a hello of a lot of sense in the scenario you describe. >> >> However, how will this positive effect be negated by data loss due to >> loss of power? There will be times where power is unexpectedly >> removed, and I would expect this scenario to be common with our user >> base. >> >> JFFS2 has done an excellent job, at least on my xos, of keeping >> filesystem integrity after sudden power-offs. > > Joel, > > Ivan and Bernardo have already made very good explanation on this. > Yes, if you > mount UBIFS with -o sync flag, you'll end up with the synchronous > FS, just like > JFFS2. Or your applications have to open files with O_SYNC, or coll > functions > like fsync(). > > Yes, JFFS2 is very good in recovery, and this comes very naturally > from its > simple design. > > In UIFS we have whole subsystem which is responsible for recovery > after unclean > reboots (fs/ubis/recovery.c). To recover, UBIFS has to replay the > journal and > remove all the garbage from the flash media. The garbage are the > half-written > UBIFS nodes in the journal (very similar to JFFS2 nodes). While > JFFS2 leaves > garbage on the media and prints CRC error messages on every reboot, > UBIFS > cleans it up during recovery procedure. > > Design-wise, I may also add that UBIFS journal is like a small > JFFS2 inside > UBIFS. From time to time the journal is committed, which means the > indexing > data structures are updated. The commit process is atomic. And the > commit does > not involve double copying of the journal data, the data physically > sits at the > same place, but gets indexed, and UBIFS picks other logical > eraseblocks for the > next journal. > > -- > Best Regards, > Artem Bityutskiy (Артём Битюцкий) > _______________________________________________ > Devel mailing list > [email protected] > http://lists.laptop.org/listinfo/devel > _______________________________________________ Devel mailing list [email protected] http://lists.laptop.org/listinfo/devel
