[ovirt-devel] bug 1041569 question was: ovirt-d] [QE][ACTION REQUIRED] oVirt 3.5.0 status (fwd)

[R P Herrold]

I was running down the open ovirt bugs, and notice this one, 
which has an outlink to a post by you (Eric) on a mailing lsit 
last month

> And the following dependencies still open:
> Bug 1041569 - [NFR] libvirt: Returning the watermark for all 
> the images opened for writing

https://www.redhat.com/archives/libvir-list/2014-August/msg00207.html

wherein you refer to a 'watermark'.  To me as a non-lingo 
aware (as to libvirt / libguestfs) developer, a watermark is a 
pattern overlaid onto an image (a pattern placed on the glue 
side of a postage stamp, or a 'DRAFT" notice on a document)

I _think_ you are referring to a 'high water mark' limit 
which, if exceeded would result in content being lost (there 
is mention of ENOSPC)

Is this accurate?  

If so, isn't this information filesystem specific and so 
something which the outsider 'container' cannot and should be 
expected to reliably know?  (I am thinking here of inode 
exhaustion even when a Linux type FS seemingly has space per: 
du ; the problem is worse with a 'sparse' capable filesystem 
in play; and seems wholly unanswerable with a Windows FS or 
some other variant)

I don't see how the hypervisor could accurately ever know this 
without 'cracking open' and asking the inside tenant .. and 
for privacy and data integrity / security reasons, the 
hypervisor should not ever be doing this

Thanks

-- Russ herrold