WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

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