multiple MTD partitions

[John Watlington]

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
> Devel at lists.laptop.org
> http://lists.laptop.org/listinfo/devel
>