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/ _______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel