Il 14/10/2013 22:10, Wolfgang Richter ha scritto: > Okay, I think my impression might be wrong, but I thought > 'drive-mirror' would become deprecated with the new 'drive-backup' > command and code. > > If we look at what they do (current documentation and code), > 'drive-backup' AFAIK behaves the same for all modes of 'drive-mirror' > _except_ mode 'none' with _better_ consistency guarantees. That is, > 'drive-backup' clearly provides a point-in-time snapshot, whereas > 'drive-mirror' may create a point-in-time snapshot, but it can not > guarantee that.
They are different. drive-backup provides a point-in-time snapshot at the time the job is started. Completing the job stops writing to the target. drive-mirror provides a copy at the time the job is completed. Completing the job stops writing to the source. > In addition, 'drive-backup's code is cleaner, simpler, and easier to > work with (in my opinion) than 'drive-mirror's code. This is because > of the new hooks in block.c for tracked requests etc. so that the job > can insert code to be run on every write in a clean manner (I think). The simpler code for drive-backup is because it doesn't have performance requirements. drive-mirror has to be optimized because otherwise too many dirty sectors pile up and the job doesn't converge. drive-backup runs synchronously as the VM writes to the disk. Using the hooks in block.c we can change drive-mirror to use an "active" (but still asynchronous) approach as long as the in-flight I/O does not exceed the size of the drive-mirror buffer. This would not simplify the code however, it would only guarantee that I/Os are performed in the same order as the original operations issued by the VM. Paolo