On 04/12/2010, at 1:29 AM, Ryan Harper wrote:

...

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.

Yeah, personally I'm in agreement with Ryan here. The "reserved" amount is mostly a throw-back concept not often used these days. SysAdmins generally kind of expect all of the "free" space to be reported/available for use. If we can only show one value, it should be the whole amount, not excluding reserved space.

* Daniel P. Berrange <berrange@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@us.ibm.com