On 02/27/2012 02:09 PM, Stefan Hajnoczi wrote: > > Non-incremental mode is "pre-copy" migration. It would stream in the > > background from the source to the destination. In this case: > > > > - you need to differentiate streaming writes from other writes. When > > streaming, you do not want to issue spurious writes to the source; > > > > - you can skip streaming anything that has been written to the > > destination already. This means that you need: 1) a bitmap similar to > > is_allocated; 2) to widen writes to a cluster; 3) serialization similar > > to copy-on-read. > > > > I'm not yet sure how much of this will be generalized in the block layer > > and block/stream.c, and how much will be specific to blkmirror, but in > > general none of this applies to blkverify. > > Agreed but I'm not sure it has to do with blkmirror either. blkmirror > and blkverify perform the same function except that blkverify mirrors > reads too and checks that they match. > > Who knows when and if pre-copy will be (re)implemented, it's not a > good argument to say let's duplicate block mirroring because we're not > sure about the design of a feature feature yet which might want to > hook in here.
It's not a duplicate, it just happens that two very simple drivers share 1 operation out of 4 (open, read, write, flush). There are other differences, for example: 1) blkverify hardcodes raw for one format and auto-detects the other. blkmirror needs to have a specified format for both, and I don't think starting another bikeshedding discussion on blkverify backwards compatibility is a good idea; 2) blkverify doesn't flush the raw file; 3) blkverify in the future could add callbacks to create snapshots or load/save imgstate, and forward them to the test file; this doesn't make sense for blkmirror. Paolo