On Thu, Apr 22, 2010 at 02:12:22PM +0200, Daniel Veillard wrote:
On Thu, Apr 22, 2010 at 02:00:56PM +0200, Daniel Veillard wrote:
> On Thu, Apr 22, 2010 at 12:43:28PM +0100, Daniel P. Berrange wrote:
> > The save process was relying on use of the shell >> append
> > operator to ensure the save data was placed after the libvirt
> > header + XML. This doesn't work for block devices though.
> > Replace this code with use of 'dd' and its 'seek' parameter.
> > This means that we need to pad the header + XML out to a
> > multiple of dd block size (in this case we choose 512).
>
> err, why ? As I pointed out dd seems just fine taking byte specified
> offset, not necessarilly multiple of 512. The main problem I see with
> this is that it does break the format and a somain saved (or managed
> save) with 0.8.0 would not restore with 0.8.1.
> I really want to understand why this is needed before going that route
> because I see this as a serious compatibility break.
Okay fater soem out of band discussion, it proves to not be a
compatibility problem becasue the length of the xml header is updated,
Confirming in the code, if you do
dd bs=512 seek=15c
Then, the way the code actually handles that is that when it processes the
ARGV, it reads the value '15', then applies the multipler 'c' (1 in this
case). When it actually comes to seek though, it will unconditionally apply
the block size multiplier too. So there is no way you can seek a value
smaller than the block size.
Daniel
--
|: Red Hat, Engineering, London -o-
http://people.redhat.com/berrange/ :|
|:
http://libvirt.org -o-
http://virt-manager.org -o-
http://deltacloud.org :|
|:
http://autobuild.org -o-
http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|