On 30/06, int32bit wrote: > Currently the size in backup is src volume size rather than backup > file/object size, it's used to record original volume size that avoid > damaging target in restore operation if the volume has been resized. > > But it may be more useful for end user to tell them backup files/objects > size(object count really make no sense for user). It's also useful for > cloud provider to compute their bill. > > I think It's not very hard to implement it if we use or extend > `chunkeddriver`. Firstly we need add `get_backup_size` new interface in > driver API and let's update backup size in `_finalize_backup`. The backend > driver should implement this interface if possible. If the backend driver > is not possible to implement like `CephBackupDriver`, we raise > NotImplementedError. And then we need add a new field(named volume_size) in > backup object as well as db model associated to backup, and store > files/objects size in original size field. At last, we add this new > field volume_size to backup ViewBuilder in API.
Hi, I think this is a good idea, just a couple of comments. We should not change the meaning of the size field in the backup model, size should remain the original volume's size, and the new field should refer to the allocated/consumed size. Besides adding the size of the hash table to the size of the chunks when calculating the consumed size of the backups, maybe we should also include a mechanism for drivers to account for the overhead of having additional objects. Last I would like to thank you for being thorough and considering the Ceph backup driver case as well, although it won't need to be an exception, as it could also report the real size of the backup with one of these 2 mechanisms: - Piping the output from export-diff and processing the metadata in there to calculate the size. - Once the backup has completed using the diff command to get the list of byte extents and calculate the real size of the image from the parent backup. Cheers, Gorka. __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev