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(a)redhat.com>
---
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