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.
Daniel