Bug 1121858 - The size of destination file is much more smaller than source after do blockcopy to an CIFS mount point
Summary: The size of destination file is much more smaller than source after do blockc...
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: qemu-kvm-rhev
Version: 7.0
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: rc
: ---
Assignee: Jeff Cody
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-07-22 05:14 UTC by Shanzhi Yu
Modified: 2016-03-28 02:55 UTC (History)
12 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-11-25 16:00:32 UTC


Attachments (Terms of Use)

Description Shanzhi Yu 2014-07-22 05:14:08 UTC
Description of problem:

The size of destination file is much more smaller than source after do blockcopy to an CIFS mount point

Version-Release number of selected component (if applicable):

# rpm -q qemu-kvm-rhev libvirt
qemu-kvm-rhev-1.5.3-60.el7ev_0.2.x86_64
libvirt-1.1.1-29.el7.x86_64

How reproducible:

100%

Steps to Reproduce:

1.Prepare samba server and mount it to local
# mount|grep cifs
//10.66.5.xxx/test on /mnt/Samba type cifs (rw,relatime,vers=1.0,cache=strict,username=root,domain=SHYU_TEST_PC,uid=0,noforceuid,gid=0,noforcegid,addr=10.66.5.xxx,file_mode=0777,dir_mode=0777,nounix,serverino,rsize=61440,wsize=65536,actimeo=1)

2. Prepare an transient guest

# virsh list --transient
 Id    Name                           State
----------------------------------------------------
 46    rhel6                          running

# virsh domblklist rhel6 
Target     Source
------------------------------------------------
vda        /var/lib/libvirt/images/rhel6.img

# qemu-img info /var/lib/libvirt/images/rhel6.img
image: /var/lib/libvirt/images/rhel6.img
file format: qcow2
virtual size: 5.0G (5368709120 bytes)
disk size: 1.2G
cluster_size: 65536
Format specific information:
    compat: 1.1
    lazy refcounts: false

3. Do blockcopy to /mnt/Samba

# virsh blockcopy rhel6 vda /mnt/Samba/copy.img --wait --verbose 
Block Copy: [100 %]
Now in mirroring phase
# virsh blockjob  rhel6 vda 
Block Copy: [100 %]

4. Check disk size of destination file

# qemu-img info /mnt/Samba/copy.img 
image: /mnt/Samba/copy.img
file format: qcow2
virtual size: 5.0G (5368709120 bytes)
disk size: 1.0M
cluster_size: 65536
Format specific information:
    compat: 1.1
    lazy refcounts: false

5. Finish the blockcopy with --pivot

# virsh blockjob rhel6 vda --pivot 

# qemu-img info /mnt/Samba/copy.img 
image: /mnt/Samba/copy.img
file format: qcow2
virtual size: 5.0G (5368709120 bytes)
disk size: 1.0M
cluster_size: 65536
Format specific information:
    compat: 1.1
    lazy refcounts: false

Actual results:


Expected results:

The "disk size" of destination should be same as source

Additional info:


ENV:

# getsebool virt_use_samba
virt_use_samba --> on
# getenforce 
Enforcing
# ll -Z /mnt/
drwxrwxrwx. root root system_u:object_r:cifs_t:s0      Samba

Comment 1 Jeff Cody 2014-11-25 16:00:32 UTC
This doesn't have anything to do with qemu or libvirt, this is a known samba bug that has been fixed in later versions.

If you go to the actual samba server, and look at the local filesystem, you will see the file is all there.  Samba is just causing the blocks used field returned by fstat to be incorrect.

If you look at other large files in the samba directory with your server, you will likely notice that 'du -sh' and 'ls -lhs' also report incorrect file sizes.

For older versions of samba, the st_blocks field returned by fstat is wrong.  I am not sure when this was fixed in samba, but with samba server version 3.6.9 (rhel 6.5), it still reports the incorrect st_blocks field.  In newer versions of samba (4.1.1, rhel 7), the st_block field in fstat is reported correctly, from my testing.

Some more reading on the original problem - I am not sure what the follow up to this was, or when this was fixed in samba: https://lkml.org/lkml/2004/9/17/235


Note You need to log in before you can comment on or make changes to this bug.