On Sat, Mar 26 2011 at 12:07pm -0400, Stuart D. Gathman <stuart@bmsi.com> wrote: > On Sat, 26 Mar 2011, Ron Johnson wrote: > > >>Yes, but a power failure can then mess up the ordering of write completions > >>distributed between 2 or more PVs, which could defeat the assumptions made > >>by your file system journaling. > > > >File a bug... But against what? LVM? The FS? The block layer? > > It is not a bug. Some progress can be made with barriers (similar to fsync()) > that block until all affected blocks are confirmed written on all devices > through all levels of the storage stack (e.g. written to all legs > of a raid1 device). My database does an fsync after each journal batch, > and I think it reasonable to hope that this guarantees that the writes > from the journal batch complete before any subsequent writes. I don't > depend on any other ordering. > > In the case of a snapshot, I believe the COW and origin blocks are written > in parallel. Snapshots are slow enough as it is. :-) So it is not > surprising that it loses consistency on power failure. The cow is completed before the origin is written. In addition, the snapshot volume offers full support for flush (barriers) to both the origin and snapshot devices. Your FUD about inconsistency due to the snapshot implementation needs to be substantiated with something more than an incoherent guesswork theory. That said, anything is possible. But if you want real help you need to be specific about which kernel you're using. What is your underlying hardware (and caching mode)? And what it was you were doing at the time of the power failure (running some FS benchmark? or what?). _______________________________________________ linux-lvm mailing list linux-lvm@redhat.com https://www.redhat.com/mailman/listinfo/linux-lvm read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
