[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [libvirt] [PATCH] Fix sparse volume allocation reporting



On Thu, Mar 26, 2009 at 05:55:00PM +0100, Daniel Veillard wrote:
> 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 ...

I guess if we come across a filesystem where it is not 512, then someone
will have created an ioctl() or equivalent to let us find out the true
value. Failing that, relying on 512 seems like a good plan.

Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]