[libvirt] [PATCH 3/4] vol-info: Check for NFS FS type

[John Ferlan]

On 08/08/2014 07:07 AM, Ján Tomko wrote:
> On 08/05/2014 04:38 PM, John Ferlan wrote:
>> 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.
> 
> Capacity should be the apparent size (what du -b shows, or st_size), while
> allocation should track the on-disk usage (du, st_blocks * 512).
> 
> It looks to me that the values are correct, it's just that posix_fallocate
> does neither work nor fail on NFS.
> 

Ah yes - this is exactly where I went back and forth on... Digging
through 'old' google results on posix_fallocate() and wondering whether
it was incorrectly returning success or whether stat() was as pointed
out in its man page not getting a reliable st_blocks value.

However, if posix_fallocate() isn't working as specified for NFS and not
producing any error message, then how does one really determine that?

I also had some code that reworked the two callers/users in order to
force the "allocation" paths to go through the slower lseek/safewrite
calls.  Is it worth resurrecting that and going with it?

John