Subject: Re: Re: mirroring: [patch 1 of 6] device failure tolerance - msg#00113

Previous Message by Date: click to view message preview

Re: mirroring: [patch 1 of 6] device failure tolerance

Hi Jonathan, or anyone else who is involved, The old patches won't apply on linux-2.6.16(.3) anymore, could you please create new patches (for linux 2.6.16) ? The previous update worked for me quite well! Thanks in advance, Dick

Next Message by Date: click to view message preview

[RFC] dm-userspace

Xen needs to be able to directly access disk formats such as QEMU's qcow, VMware's vmdk, and possibly others. Most of these formats are based on copy-on-write ideas, and thus have a base image and a bunch of modified blocks stored elsewhere. Presenting this to a virtual machine transparently as a normal block device would be ideal. The solution I propose is to use device-mapper for redirecting block accesses to the appropriate locations within either the base image or the COW space, with the following constraints: 1. The block-allocation algorithm and formatting scheme should not be in the kernel. This gives the most flexibility and puts the complexity in userspace. 2. Actual data flow should happen only in the kernel, and userspace should be able to control it without the blocks being passed back and forth. So, I developed a generic device-mapper target called dm-userspace which allows a userspace application to control the block mapping in a mostly generic way. With the functionality it provides, I was able to write a userspace daemon that handles the mapping of blocks such that a qcow file could be presented as a single block device, mounted and accessed as if it were a normal disk. If/when VMware releases their vmdk spec under the GPL, adding support for it would be relatively simple. This would give us a unified block device to export to the virtual machine, that would be backed by a complex format such as vmdk or qcow. In addition to providing support for the above scenario, dm-userspace could be used for other things as well. It's possible that new device-mapper targets could be developed in userspace using a special application that used dm-userspace to simulate the kernel environment. Additionally, filesystem debuggers may be able to use dm-userspace to provide interactive control and logging of disk writes. A patch against 2.6.16.9 to add dm-userspace to the kernel is available here: http://static.danplanet.com/dm-userspace/dmu-2.6.16.9.patch After you have a patched kernel, you can build the (very tiny) helper library and example program, available here: http://static.danplanet.com/dm-userspace/libdmu-0.1.tar.gz Comments would be appreciated :) -- Dan Smith IBM Linux Technology Center Open Hypervisor Team email: danms@xxxxxxxxxx pgppuKohg0M3n.pgp Description: PGP signature

Previous Message by Thread: click to view message preview

Re: mirroring: [patch 1 of 6] device failure tolerance

Hi Jonathan, or anyone else who is involved, The old patches won't apply on linux-2.6.16(.3) anymore, could you please create new patches (for linux 2.6.16) ? The previous update worked for me quite well! Thanks in advance, Dick

Next Message by Thread: click to view message preview

Multipath and SCSI_STATUS

I have a question related to SCSI_STATUS and multipath, which I hope someone can answer. Will a hardware_handler get called at its error function when a Unit Attention occurs on a multipath device, will the Sense Status be available. I?m running RHEL 4 update 2 Thanks in advance, Bart