https://bugzilla.redhat.com/show_bug.cgi?id=1077068 Check for the NFS FS type being true for a "local" stat of the file to force usage of the 'st_size' value rather than calculating the size using the 'st_blocks' and 'st_blksize'. As described in the stat(2) man page: "Use of the st_blocks and st_blksize fields may be less portable." experimentation shows a 10M file could get the following output from stat: st_size=10485760 st_blocks=88 st_blksize=1048576 resulting in a "44 KiB" value being displayed as the allocation value. While this value does match the "du -s" value of the same file, the "du -b" value shows the "st_size" field. Similarly a long listing of the file shows the 10M size. Prior to the change: Name: test-vol1 Type: file Capacity: 10.00 MiB Allocation: 44.00 KiB After the change: Name: test-vol1 Type: file Capacity: 10.00 MiB Allocation: 10.00 MiB Signed-off-by: John Ferlan <jferlan@xxxxxxxxxx> --- src/storage/storage_backend.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/src/storage/storage_backend.c b/src/storage/storage_backend.c index 5cada39..bbc992e 100644 --- a/src/storage/storage_backend.c +++ b/src/storage/storage_backend.c @@ -1520,8 +1520,11 @@ virStorageBackendUpdateVolTargetInfoFD(virStorageSourcePtr target, if (S_ISREG(sb->st_mode)) { #ifndef WIN32 - target->allocation = (unsigned long long)sb->st_blocks * - (unsigned long long)DEV_BSIZE; + if (virFileIsNFSFSType(target->path)) + target->allocation = sb->st_size; + else + target->allocation = (unsigned long long)sb->st_blocks * + (unsigned long long)DEV_BSIZE; #else target->allocation = sb->st_size; #endif -- 1.9.3 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list