Bug 518509 - Data loss/corruption when removing disks from Windows guests
Summary: Data loss/corruption when removing disks from Windows guests
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: xenpv-win
Version: 5.3
Hardware: All
OS: Linux
high
high
Target Milestone: rc
: ---
Assignee: Paolo Bonzini
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks: 501027 518405
TreeView+ depends on / blocked
 
Reported: 2009-08-20 16:24 UTC by Paolo Bonzini
Modified: 2013-01-11 02:34 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of: 501027
Environment:
Last Closed: 2009-11-16 13:44:46 UTC


Attachments (Terms of Use)
mark PV drives as removable (896 bytes, patch)
2009-09-22 16:30 UTC, Paolo Bonzini
no flags Details | Diff


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHEA-2009:1583 normal SHIPPED_LIVE xenpv-win bug fix and enhancement update 2009-11-16 13:44:33 UTC

Description Paolo Bonzini 2009-08-20 16:24:37 UTC
It is possible to lose data while detaching hard drives from Windows guests running on xenpv-win drivers.  This is likely because windows use disk caching which does not get flushed upon detach.  "xm block-detach" can be compared to hard removing a USB drive and as such can cause data loss for all cached data inside domU.  If you go to disk properties, however, the option to turn off disk caching is grayed out.

In order to safely detach a block device, it's necessary first to force writing all data (sync -r) and detach the volume (mountvol /d).  Before doing so, in turn, one should check that no handles are open within the volume.  Automating this process would be desirable, as it would eliminate the chance of data loss due to not following these steps or not following them properly.

In order to fix this problem, there are different possible options.

1. Figuring out the reason that is graying out the option to turn caching on/off. Can disk PV-drivers be responsible for this in some way? Have you seen similar behavior in your lab testing? We will really appreciate if you can help us track this down.

2.When a backend disk driver receives a request to detach a disk drive from DOMU, does it first send any notification to frontend PV driver in DomU?  If there is any such a notification and if PV driver propagates that notification up the disk driver stack properly, then the volume driver should flush the cache before tearing down the stack.  If there is no such notification, is it possible to add such notification?

3. In Linux, if a disk drive is mounted inside DOMU and a detach command is issued, the command fails with error device busy.  This means that some message exchange happens between DOM0 and DOMU before detaching the device.  Does a similar message exchange happen for windows?  If so can we trap that message in user mode to automate cache flushing if #2 is not possible.

4. Does disk PV driver satisfy all the pnp criteria mentioned in this page http://msdn.microsoft.com/en-us/library/ms802356.aspx

Comment 1 Paolo Bonzini 2009-09-22 16:30:26 UTC
Created attachment 362118 [details]
mark PV drives as removable

For now we'll be marking Xen PV drives as removable.  This affects Windows in several ways:

1) every user will be able to format the drive

2) only the first partition of the drive will be accessible

3) the context menu for the drive in "My Computer" will show an Eject menu
item.  (At least in Vista and 2008 Server; the details may vary in XP and 2003
Server).

The workaround, then, is to explicitly eject the drive (and wait for Windows to
unmount it, which may take 10-15 seconds) before detaching the block device
from dom0.

I'm moving this bug into POST, seeking a better solution that does not require domU intervention can be done in another bug.

Comment 2 Paolo Bonzini 2009-10-12 08:27:18 UTC
Fixed for real in 1.0.91-1.

Comment 4 koka xiong 2009-11-02 08:40:20 UTC
1.Install win2003/32 guest
2.Install xenpv-win driver
3.Run dd if=/dev/zero of=disk1.img bs=1M count=4096
4.Run xm block-attach win03_32 tap:aio:/root/disk1.img /dev/hdb w
5.Format the new attached disk
6.Create a notepad write some text then save it
7.Run xm block-detach win03_32 /dev/hdb
8.Run xm block-attach win03_32 tap:aio:/root/disk1.img /dev/hdb w
9.Verify the saved file is still there.
10.Repeat the step6--step9 several times,the notepad isn't lost.
Verification is passed.

Comment 6 errata-xmlrpc 2009-11-16 13:44:46 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHEA-2009-1583.html


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