Seems like this didn't make it through to the list the first time... * Aidan Van Dyk <aidan@xxxxxxxxxxx> [081106 22:19]: > * David Rees <drees76@xxxxxxxxx> [081106 21:22]: > > > 2. A write barrier instructs the lower level hardware that commands > > issued before the barrier must be written to disk before commands > > issued after the barrier. Write barriers are used to ensure that data > > written to disk is written in such a way as to maintain filesystem > > consistency, without losing all the benefits of a write cache. > > > > 3. A fsync call forces data to be synced to the controller. > > > > This means that whenever you call fsync, at the very minimum, the data > > will have made it to the controller. How much further down the line > > will depend on whether or not the controller is in WriteBack or > > WriteThrough mode and whether or not the disk is also caching writes. > > > > So in your example, if the OS is caching some writes and fsync is > > called, it won't be returned until at a minimum the controller has > > accepted all the data, regardless of whether or not write barriers are > > enabled. > > > > In theory, it should be safe to disable write barriers if you have a > > BBU because the BBU should guarantee that all writes will eventually > > make it to disk (or at least reduce the risk of that not happening to > > an acceptable level). > > All that's "correct", but note that fsync doesn't guarentee *coherent* > filesystem state has been made to controller. And fsync *can* carry "later" > writes to the controller. > > I belive the particular case the prompted the write-barriers to become default > was ext3 + journals, where in certain (rare) cases, upon recovery, things were > out of sync. What was happening was that ext3 was syncing the journal, but > "extra" writes were getting carried to the controller during the sync > operation, and if something crashed at the right time, "new" data was on the > disk where the "old journal" (because the new journal hadn't finished making > it to the controller) didn't expect it. > > The write barriers give the FS the symantics to say "all previous queue > writes" [BARRIER] flush to controller [BARRIER] "any new writes", and thus > guarentee the ordering of certian operations to disk, and guarentee coherency > of the FS at all times. > > Of course, that guarenteed FS consistency comes at a cost. As to it's > necessity with the way PG uses the FS w/ WAL.... or it's necessity with > xfs... > > a. > > -- > Aidan Van Dyk Create like a god, > aidan@xxxxxxxxxxx command like a king, > http://www.highrise.ca/ work like a slave. -- Aidan Van Dyk Create like a god, aidan@xxxxxxxxxxx command like a king, http://www.highrise.ca/ work like a slave.
Attachment:
signature.asc
Description: Digital signature
