[libvirt] directory storage pools reported available space

[Ryan Harper]

* Daniel P. Berrange <berrange at redhat.com> [2010-12-06 05:03]:
> On Fri, Dec 03, 2010 at 12:00:39AM -0600, Ryan Harper wrote:
> > We recently had an issue with not being able to allocate the full
> > capacity of a directory based storage pool.  The reported value via
> > pool-info was larger than what was available to the image creator.
> > 
> > Looking at the storage code, in virStorageBackendFileSystemRefresh()
> > we're using statvfs, and reporting back 
> > 
> >    pool->def->available = ((unsigned long long)sb.f_bfree *
> >                           (unsigned long long)sb.f_bsize);
> > 
> > Which is the amount of blocks available, including any root reservation
> > if present on the filesystem.
> > 
> > This does't line up with df output , which at least on RHEL5 and 6
> > systems reports the available space from f_bavail, which excludes
> > and reserved space.
> > 
> > Is it reasonable to have the available value line up with output from df
> > and not report reserved space?
> 
> I guess it depends on the usage scenario :-(  If you're allocating
> a disk volume upfront with qemu://system, then reserved space is
> irrelevant since libvirtd (which does the pre-allocation) is running
> as root. If you are running qemu://session then we're non-root so
> reserved space does matter.  With sparse files, reserved space does
> matter if you want to calculate overcommit since QEMU runs non-root.
> The problem is that I don't really see how to nicely fit this into
> the storage pool model.

I agree there isn't a really good solution, but I think most folks would
prefer to find out that have more storage available than be told they
have more than they can access.  I'd much prefer writing documentation
on how to tune the filesystem to remove the reserved access thant
providing the calculation to adjust down the value.

If we report non-reserved values we match other storage tools like df
and I think there is a lot of value in matching common tool output here.

I really do believe non-reserved should be the default; we can add a new
field to report both, or even an optional field only displayed if you do

virsh pool-info --reserved 

or something like that.


-- 
Ryan Harper
Software Engineer; Linux Technology Center
IBM Corp., Austin, Tx
ryanh at us.ibm.com