On 07/27/11 18:40, Andrea Arcangeli wrote: >> Another thing to note is that snapshotting is not necessarily something >> > that should be completely transparent to the guest. One of the planned >> > future features for the guest agent (mentioned in the snapshot wiki, and >> > a common use case that I've seen come up elsewhere as well in the >> > context of database applications), is a way for userspace applications >> > to register callbacks to be made in the event of a freeze (dumping >> > application-managed caches to disk and things along that line). The > Not sure if the scripts are really needed or if they would just open a > brand new fsfreeze specific unix domain socket (created by the > database) to tell the database to freeze. > > If the latter is the case, then it'd be better rather than changing > the database to open unix domain socket so the script can connect to > it when invoked (or maybe to just add some new function to the > protocol of an existing open unix domain socket), to instead change > the database to open a /dev/virtio-fsfreeze device, created by the > virtio-fsfreeze.ko virtio driver through udev. The database would poll > it, and it could read the request to freeze, and write into it that it > finished freezing when done. Then when all openers of the device > freezed, the virtio-fsfreeze.ko would go ahead freezing all the > filesystems, and then tell qemu when it's finished freezing. Then qemu > can finally block all the I/O and tell libvirt to go ahead with the > snapshot.
I think it could also be a combined operation, ie. having the freeze happen in the kernel, but doing the callouts using a userspace daemon. I like the userspace daemon for the callouts because it allows providing a more sophisticated API than if we provide just a socket like interface. In addition the callout is less critical wrt crashes than the fsfreeze operations. Cheers, Jes