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

[Ewan Mellor <ewan@xxxxxxxxxxxxx>]

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);


Catting the whole device to determine its size is vile, and would slow down
the regression suite unnecessarily.  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.

Ewan.

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