> From: Adam Levin [mailto:levi...@gmail.com] > > It certainly deserves > a second look as to whether this quiescing stuff is necessary.
FWIW, I don't advise *not* quiescing. At worst, it does no harm, and at best, it might be important. But I don't do snapshots in vmware - and don't do quiescing myself, basically because I'm confident in all the other stuff, and only have the tiny littlest miniscule tiny little bit of additional confidence added by quiescing. For example: Everyone always talks about quiescing as it relates to VSS. This is kind of questionable, because how many applications register as VSS writers, but don't provide consistency just as a general design characteristic? What kind of application would provide a mechanism to ensure consistency for *graceful* crashes or snapshots, but fail to provide consistency for *ungraceful* crashes? The number is probably nonzero, but I have doubts that it's very significant. And what about non-windows VM's? Technically, anywhere vmware tools is running, it might theoretically have hooks into the OS to flush write buffers and so on. But does it really apply to non-windows guests? To what extent? I know you can cause the linux kernel to flush buffers by echoing some magic into /proc, and I would assume vmware tools in linux probably does that upon quiesce request. But I would also assert that doing so is usually *counter* productive, causing a miniscule performance hit without any g ain - because the data that exists in buffers was not harmful to exist in buffers. The stuff that needed to be flushed to disk in order to maintain filesystem and database consistency had already been flushed to disk. _______________________________________________ Tech mailing list Tech@lists.lopsa.org https://lists.lopsa.org/cgi-bin/mailman/listinfo/tech This list provided by the League of Professional System Administrators http://lopsa.org/
