> > AFAIK qcow2 file cannot store data out of order. In general, an backup > > fd is not seekable, and we only want to do sequential writes. Image format > always requires seekable fds? > > Ah, this is what you mean by "out of order". Just out of curiosity, what are > these non-seekable backup fds usually?
/dev/nst0 ;-) But there are better examples. Usually you want to use some kind of compression, and you do that with existing tools: # backup to stdout|gzip|... A common usage scenario is to pipe a backup into a restore (copy) # backup to stdout|ssh to remote host -c 'restore from stdin' It is also a performance question. Seeks are terrible slow. > In principle even for this qcow2 could be used as an image format, however > the existing implementation wouldn't be of much use for you, so it loses > quite a bit of its attractiveness. > > > Anyways, a qcow2 file is really complex beast - I am quite unsure if I > > would use that for backup if it is possible. > > > > That would require any external tool to include >=50000 LOC > > > > The vma reader code is about 700 LOC (quite easy). > > So what? qemu-img is already there. Anyways, you already pointed out that the existing implementation does not work. But I already expected such discussion. So maybe it is better we simply pipe all data to an external binary? We just need to define a minimal protocol. In future we can produce different archivers as independent/external binaries?