[libvirt] [PATCH 3/4] vol-info: Check for NFS FS type
John Ferlan
jferlan at redhat.com
Fri Aug 8 22:28:03 UTC 2014
On 08/08/2014 11:26 AM, John Ferlan wrote:
>
>
> 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.
>>
>> Jan
>>
>
> Testing seems to indicate that posix_fallocate() either doesn't work as
> expected on the target or using the target.path is incorrect...
>
> Before posix_fallocate
> stat st_blocks=0 st_blksize=1048576 st_size=10485760
> lseek end=10485760
>
> posix_fallocate of 10485760 bytes on /home/nfs_pool/target/test-vol1
>
> After posix_fallocate
> stat st_blocks=88 st_blksize=1048576 st_size=10485760
> lseek end=10485760
>
>
> Hmm... would going at the target be correct in this instance? Same test
> but use the source path:
>
> Before posix_fallocate
> stat st_blocks=0 st_blksize=4096 st_size=10485760
> lseek end=10485760
>
> posix_fallocate of 10485760 bytes on /home/nfs_pool/nfs-export/test-vol1
>
> After posix_fallocate
> stat st_blocks=20480 st_blksize=4096 st_size=10485760
> lseek end=10485760
>
> ...
>
> hmm.... 20480 * 512 = 10485760
>
> # df
> ...
> localhost:/home/nfs_pool/nfs-export 140979200 35521536 98273280 27%
> /home/nfs_pool/target
> #
>
Well it's a tangled web that's being weaved... The blksize of the
target volume comes from the 'wsize' value in the mount:
localhost:/home/nfs_pool/nfs-export on /home/nfs_pool/target type nfs4
(rw,relatime,vers=4.0,rsize=1048576,wsize=1048576,...)
Further testing shows if I change the wsize to 4096, then I get what I
expect; however, starting at 8192 I'll get decreasingly smaller
allocations. So this is a "math problem".
So going back to writing via posix_fallocate() to the
"/home/nfs_pool/target/test-vol" the "issue" is the blksize of the
"source" (nfs-export) is 4096 while the blksize of the "target" (target)
is 1048576 (as a result of the nfs mount settings). What "seems" to
happen is the posix_fallocate() makes 11 "writes" - I assume because
blksize*10 < desired_size (10485760) (instead of <=...).
Thus 11 * 4096 = 45056 (bytes) / 1024 = 44 KiB which was displayed.
Why all this happens I'm not sure. Bug in posix_fallocate()? Bug in
configuration? I have to assume that when this code was first added NFS
probably was still using smaller block sizes. Whether anyone has
noticed or not beyond the virt-test which discovered the issue - I'm not
sure. In any case, does anyone have feedback/thoughts for next steps?
I can put together something that avoids posix_fallocate() for the
create-as and resize paths.
John
More information about the libvir-list
mailing list