[libvirt] [PATCH] Fix sparse volume allocation reporting

Daniel Veillard veillard at redhat.com
Thu Mar 26 16:55:00 UTC 2009


On Thu, Mar 26, 2009 at 01:19:12PM +0000, Daniel P. Berrange wrote:
> On Tue, Mar 24, 2009 at 03:29:21PM -0400, Cole Robinson wrote:
[...]
> Having read the man page again, I'm inclined to say using st_blksize
> is always wrong no matter what, because it is quite clear that 'st_blocks'
> is always in 512 byte units. So perhaps we might be better of doing
> 
>    #ifndef DEV_BSIZE
>    #define DEV_BSIZE 512
>    #endif
> 
> And then always using DEV_BSIZE. 

  In those kind of cases I go down to the spec and it states (in the
informative section though):

-----------------------------------------
http://www.opengroup.org/onlinepubs/000095399/basedefs/sys/stat.h.html
"The unit for the st_blocks member of the stat structure is not defined
within IEEE Std 1003.1-2001. In some implementations it is 512 bytes. It
may differ on a file system basis. There is no correlation between
values of the st_blocks and st_blksize, and the f_bsize (from
<sys/statvfs.h>) structure members.

Traditionally, some implementations defined the multiplier for st_blocks
in <sys/param.h> as the symbol DEV_BSIZE."
-----------------------------------------

  So I agree with Dan, we need to drop st_blksize in any volume size
computation, and fallback to 512 if not defined, apparently only
src/storage_backend.c referenced it :-)

  I still find the "It may differ on a file system basis" to be a bit
frightening considering the sandard doesn't seems to indicate how to
extract that information from the filesystem :-( , oh well ...

Daniel

-- 
Daniel Veillard      | libxml Gnome XML XSLT toolkit  http://xmlsoft.org/
daniel at veillard.com  | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library  http://libvirt.org/




More information about the libvir-list mailing list