Bug 658764 - virsh vol-wipe can't wipe up the volume completely in one time
Summary: virsh vol-wipe can't wipe up the volume completely in one time
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: libvirt
Version: 5.6
Hardware: Unspecified
OS: Unspecified
low
medium
Target Milestone: rc
: ---
Assignee: Osier Yang
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-12-01 08:28 UTC by Vivian Bian
Modified: 2011-10-17 15:22 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-10-17 15:22:45 UTC
Target Upstream Version:


Attachments (Terms of Use)
bytes that wasn't wiped on the volume (1.05 KB, application/octet-stream)
2010-12-02 03:26 UTC, Vivian Bian
no flags Details

Description Vivian Bian 2010-12-01 08:28:05 UTC
Description of problem:
#  virsh vol-wipe /dev/lv_pool/lv_test
Vol /dev/lv_pool/lv_test wiped

# cmp /dev/lv_pool/lv_test /dev/zero 
/dev/lv_pool/lv_test /dev/zero differ: byte 2576412, line 1


#  virsh vol-wipe /dev/lv_pool/lv_test
Vol /dev/lv_pool/lv_test wiped

# cmp /dev/lv_pool/lv_test /dev/zero 
cmp: EOF on /dev/lv_pool/lv_test

Version-Release number of selected component (if applicable):
libvirt-0.8.2-14.el5

How reproducible:
always

Steps to Reproduce:
1. create a logical volume pool with xml similar with following:

      <pool type="logical">
        <name>lv_pool</name>
        <source>
          <device path="/dev/sda3"/>
          <device path="/dev/sdb4"/>
          <device path="/dev/sdc5"/>
        </source>
        <target>
          <path>/dev/lv_pool</path>
        </target>
      </pool>

  # virsh pool-define lv_pool.xml
 # virsh pool-build lv_pool 
 # virsh pool-start lv_pool

2. create a logical volume with xml similar with following:
   <volume>
  <name>lv_test</name>
  <key>r4xkCv-MQhr-WKIT-R66x-Epn2-e8hG-1Z5gY0</key>
  <source>
    <device path='/dev/sda3'>
    </device>
  </source>
  <capacity>2080374784</capacity>
  <allocation>2080374784</allocation>
  <target>
    <path>/dev/lv_pool/lv_test</path>
    <permissions>
      <mode>0660</mode>
      <owner>0</owner>
      <group>6</group>
      <label>system_u:object_r:fixed_disk_device_t:s0</label>
    </permissions>
  </target>
</volume>

# virsh vol-create lv_pool lv_test.xml


3. check if the volume exists
 # virsh vol-list lv_pool
Name                 Path                                    
-----------------------------------------
lv_test              /dev/lv_pool/lv_test

4. mount /dev/lv_pool/lv_test
# mkfs.ext3 /dev/lv_pool/lv_test
# mount /dev/lv_pool/lv_test /mnt

5. write some datas to /dev/lv_pool/lv_test
  # cd /mnt
  # for i in {1..100}; do touch "hello${i}"; done
  for i in {1..100};do echo "hello, girl" >> hello${i}; done

6. wipe
  # virsh vol-wipe ${lv_test_path}

7. check if it's empty
#cmp  ${lv_test_path}  /dev/zero
 
8. remount /dev/lv_pool/lv_test
  
Actual results:
as $description

Expected results:
could wipe up the volume in one time 

Additional info:

Comment 1 Vivian Bian 2010-12-01 09:37:43 UTC
on RHEL6 did the same operation with the comment 0 , and the volume could be wiped up in one time . 

libvirt-0.8.1-27.el6.x86_64
kernel-2.6.32-71.el6.x86_64

steps did on RHEL6 

[root@dhcp-93-211 ~]# vim pool.xml
[root@dhcp-93-211 ~]# virsh pool-define pool.xml 
Pool lv_pool defined from pool.xml

[root@dhcp-93-211 ~]# virsh pool-build lv_pool
Pool lv_pool built

[root@dhcp-93-211 ~]# virsh pool-start lv_pool
Pool lv_pool started

[root@dhcp-93-211 ~]# vim vol.xml
[root@dhcp-93-211 ~]# virsh vol-create lv_pool vol.xml 
Vol lv_test created from vol.xml

[root@dhcp-93-211 ~]# mkfs.ext3 /dev/lv_pool/lv_test 
......

[root@dhcp-93-211 ~]# mount /dev/lv_pool/lv_test /mnt
[root@dhcp-93-211 ~]# cd /mnt; for i in {1..100}; do touch "hello${i}"; done
[root@dhcp-93-211 mnt]# virsh vol-wipe /dev/lv_pool/lv_test 
Vol /dev/lv_pool/lv_test wiped

[root@dhcp-93-211 mnt]# cmp /dev/lv_pool/lv_test /dev/zero 
cmp: EOF on /dev/lv_pool/lv_test

Comment 2 Vivian Bian 2010-12-01 09:39:26 UTC
all of the xml files in comment 0 and comment 1 are the same

Comment 3 Dave Allan 2010-12-01 15:15:33 UTC
Can you provide the bytes that are non-zero?

Comment 4 Vivian Bian 2010-12-02 03:26:51 UTC
Created attachment 464155 [details]
bytes that wasn't wiped on the volume

# cmp /dev/lv_pool/lv_test /dev/zero 
/dev/lv_pool/lv_test /dev/zero differ: byte 1073, line 1

# dd if=/dev/lv_pool/lv_test of=/opt/un-wiped-bytes bs=1073 count=1
1+0 records in
1+0 records out
1073 bytes (1.1 kB) copied, 0.0001 seconds, 11 MB/s

# cat /opt/un-wiped-bytes 
�

Comment 8 Osier Yang 2011-08-16 10:45:46 UTC
Can't reproduce this with many times testing. The codes looks good to me, have
no idea what happened.

@vivian, if it still could be reproduced for you, please execute the "cmp"
command
with option "-l", it will print the differing bytes (though actually it's only
one byte difference in your result). It might help us. And I'm not sure if it
caused by
some byte we actually should skip. Please refer to the "-i SKIP1:SKIP2" or "-i
SKIP" of the cmp manual, and try to do some testing with it. Thanks.

Comment 9 Vivian Bian 2011-08-18 07:18:44 UTC
can't reproduce this bug on 
libvirt-0.8.2-22.el5
kernel-2.6.18-278.el5

# cmp -l /dev/lv_pool/lv_test /dev/zero 
            2576412   2   0
            2576416   1   0
            2576417 377   0
            2576418 377   0
            2576419 377   0
            2576420 373   0
cmp: EOF on /dev/lv_pool/lv_test

Comment 10 Dave Allan 2011-10-17 15:22:45 UTC
(In reply to comment #9)
> can't reproduce this bug on 
> libvirt-0.8.2-22.el5
> kernel-2.6.18-278.el5
> 
> # cmp -l /dev/lv_pool/lv_test /dev/zero 
>             2576412   2   0
>             2576416   1   0
>             2576417 377   0
>             2576418 377   0
>             2576419 377   0
>             2576420 373   0
> cmp: EOF on /dev/lv_pool/lv_test

I'll close as WORKSFORME, and please reopen if it reappears.


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