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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list