[revisiting something that finally surfaced to the top of my todo list] On 08/07/2014 03:57 AM, Peter Krempa wrote: > On 08/06/14 18:36, Eric Blake wrote: >> Adam Litke has been asking if I can expose watermark information from\ > > <bikeshedding> > I'd be glad if we stopped calling this watermark. The wiki > disambiguation article states: > > <citation> > A watermark is a recognizable image or pattern in paper used to identify > authenticity. > > Watermark or watermarking can also refer to: > > In digital watermarks and digital security[edit] > Watermark (data file), a method for ensuring data integrity which > combines aspects of data hashing and digital watermarking > Watermark (data synchronization), directory synchronization related > programming terminology > High-water mark (computer security), We are using it in the sense of high-water mark. Etymology-wise, it goes back to the days of loading boats - you would paint a line called the high watermark; as the boat was weighed down with more cargo, you had to stop loading when that line touched the water, or risk sinking the boat. In the same vein, someone running on expandable underlying storage can let the guest consume until it hits the watermark, at which point the storage must be grown to avoid sinking the guest with an out-of-space event. But I'm open to the idea of any other terminology... For now, calling it allocation is good enough, since that is the term I will be putting in the XML. >> >> The other idea I've had is to expand the <domain> XML to expose more >> information about backing chains, including to make it expose details >> that are redundant with virDomainBlockInfo() for the top level, or maybe >> even what virDomainBlockStatsFlags() reports. Here, we have a bit of a >> choice - storage volume XML was inconsistent on which attributes were >> siblings to <target> (such as <capacity>) vs. children (such as >> <timestamps>); it might be nicer to stick all per-file elements at the >> same level in <disk> XML (probably as siblings to <source>). On the >> other hand, I strongly feel that <compat> is a feature of the <format>, >> so it should have been a child rather than a sibling. So, as an example >> of what the XML might look like: >> >> <disk type='file' device='disk'> >> <driver name='qemu' type='qcow2'> >> <compat>1.1</compat> >> <features/> >> </driver> >> <source file='/tmp/snap2.img'/> >> <capacity unit='bytes'>12884901888</capacity> >> <allocation unit='bytes'>2503548928</allocation> >> <physical unit='bytes'>2503548928</allocation> >> <permissions> >> <mode>0600</mode> >> <owner>107</owner> >> <group>107</group> >> <label>system_u:object_r:virt_content_t:s0</label> >> </permissions> >> <timestamps> >> <atime>1407295598.623411816</atime> >> <mtime>1402005765.810488875</mtime> >> <ctime>1404318523.313955796</ctime> >> </timestamps> > > Both <permissions> and <timestamps> are not entirely useful information > in runtime. Maybe not entirely useful, but fairly easy to learn and awfully similar to storage volume XML. But we can do this incrementally, the real request I have is for allocation; and while I think permissions and timestamps may be useful to shave off later API calls, I don't think it is a showstopper if they are not present in the first cut that adds allocation. >> >> Again, this is a lot of new information, so it may be wise to add a new >> flag that must be turned on to request the information. But adding this > > This definitely needs a flag. We are polluting the XML enough by the > backing chain now. Okay, I'll be proposing a patch with the new flag shortly. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list