multiple MTD partitions

[Bernardo Innocenti]

Joel Stanley wrote:

> 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.

The semantics of the UNIX filesystem have always been that
writes are asynchronous and thus potentially incomplete by
the time write() returns.

If an application needs to ensure some data has been completely
written to permanent storage before proceeding, it needs to
explicitly call one of fsync(), fdatasync() or sync().

It is customary for SMTP servers to call fsync() before issuing
the final OK to the client.  This should be strongly guaranteed
by any sanely implemented filesystem, regardless of journaling
and cache write back.

For the majority of applications that don't specify when to
flush explicitly, the kernel has a bdflush daemon which forces
dirty pages to disk with a configurable timeout.  The default
was around 30 seconds IIRC.  This seems like a good compromise
between data integrity and efficiency.

I was arguing with David and Ivan earlier that it may be smarter
for the kernel to initiate flushing pages in the background
whenever the disk seems idle.  So the bandwidth doesn't go
wasted while there's pending work to do soon.

A counter argument could be that using some I/O channels may not
be cheap in terms of CPU time and memory bandwidth.  Also, some
disks live on shared buses too, so the heuristic needs to be a
little smarter than what I described.


> JFFS2 has done an excellent job, at least on my xos, of keeping
> filesystem integrity after sudden power-offs.

Same experience here.

-- 
 \___/
 |___|   Bernardo Innocenti - http://www.codewiz.org/
  \___\  One Laptop Per Child - http://www.laptop.org/