Re: [Xen-devel] [PATCH] [XM-TEST] block device write verify test 2nd attempt

[Harry Butterworth <harry@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx>]

On Wed, 2006-05-24 at 13:37 +0100, Ewan Mellor wrote:
> On Wed, May 24, 2006 at 12:08:28PM +0100, Harry Butterworth wrote:
> 
> > > > > Why don't you just fix the size of the datablock that you write to the
> > > > > ramdisk, instead of determining the current size of the ramdisk with 
> > > > > cat
> > > > > /dev/hda1 | wc -c?
> > > > 
> > > > I wanted to test writing at the device limits.  Sometimes there are off
> > > > by one errors that mean you can't write the last sector of a block
> > > > device.
> > > > 
> > > > cat | wc -c was the most robust way I could think of for getting the
> > > > size.
> > > 
> > > How about blockdev --getsize64 /dev/ram1?
> > 
> > blockdev and stat are not available in the ramdisk.  I could use
> > blockdev to get the blocksize and number of blocks in dom0 and then pass
> > the values to domU but it would be better to obtain all the information
> > in domU since that would test whether the size of the device is
> > correctly passed from the back to the front by the blk driver.
> > 
> > The test as it stands does check that aspect of the blk driver operation
> > and is only a factor of 2 slower than the limit and the python code is
> > trivial so I thought it was reasonable.
> > 
> > Can you think of any way to get the block size and number of blocks
> > using tools available on the ramdisk?
> 
> dd if=/dev/urandom of=/dev/ram1 bs=512 count=`cat /sys/block/ram1/size`

> The value in /sys/block/ram1/size is defined to be in multiples of 512 bytes,
> as rd.c shows:
> 
>               /* rd_size is given in kB */
>                 ...
>               set_capacity(disk, rd_size * 2);

OK, thanks I'll use that.

> Modifying the ramdisk is not verboten,
> but it is a right pain in the backside for everyone, particularly me because I
> need to build a new one and upload it and all of its source (because of the
> GPL) to xm-test.xensource.com.

The current test is modifying the ramdisk to add `tee` (as well as fancy
head which we don't need anymore).

Are you going to accept the patch if it requires the addition of `tee`
to the ramdisk?  Or should I change the test to read the data back in
domU---which I was specifically trying to avoid.

The problem with reading the data back in domU after having written it
is that it might mask bugs in the block driver.  Reading the data back
might cause it to be committed to the device where otherwise a bug might
cause it to be lost.

Harry.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel