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?

> It's misleading not to exclude the reserved space, probly it will be > nicer to report both the actually avaiable spaces and the reserved > ones. I argue the opposite. df doesn't show you the reserved space. the first thing someone does to compare the values between libvirt directory pool and df. I don't mind reporting both but, I've yet to see a tool to report the reserved value rather than the non-reserved.

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.