On 30 Aug, Matthias Buelow wrote: > Jon Dama wrote: > >>Ironically, phk backed out the underlying support for this safety fix >> from the FreeBSD kernel b.c. it wasn't integrated into the softupdates >>code >>whereas in reality the proper course of action would have been to hook it >>in. :-/ > > Can it be put into softupdates at all? From what I understand (which > is probably a rather sketchy idea of the matter), write barriers > work because they are only used here to separate journal writes > from data writes (i.e., to make sure the log is written, by flushing > the cache, before any filesystem data hits the platters). I've read > the softupdates paper some time ago and haven't found similar > sequence points where one could insert such flushing. One would > have to "flush" all the time, either continuously or in very short > intervals, in order to keep the ordering, which then would amount > to the same effects as if one simply disabled the cache. But probably > I'm wrong here (I hope).
Performance might be bad, but it is still likely to be better than totally disabling write caching. For instance if you had two different write transaction pairs, where write B depends on write A, and write D depends on write C, you could issue writes A and C, flush the drive's write cache, and then issue writes B and D. You could also optimize large sequential writes by writing all the data blocks, flushing the write cache, and then updating the inode and bitmap blocks. Grouping writes to minimize the number of flushes might help performance. The key is that the drive's write cache needs to be flushed before doing a write that depends on an earlier write. The complication is that softupdates tosses the information about a write as soon as the drive acknowledges it, but if write caching is enabled, softupdates would need to retain this information until the drive's write cache is flushed. I think you could still get file system corruption on power failure if you are using ATA drives, because most high capacity drives write a track at a time, in many cases re-writing data that was last touched in the distant past. If the power fails part way through a track rewrite, then the old data on that track may be lost. _______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
