mpt + gvinum on 6.0-BETA1

Scott Long scottl at samsco.org
Sat Aug 6 17:57:27 GMT 2005


Matthias Schuendehuette wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hi, I try this on -current again:
> 
>> I tried 6.0-BETA1 on one of our FUJITSU-SIEMENS RX300 S2 servers  and 
>> it seems that I have problems with the disk subsystem, even  after 
>> Scotts major overhaul of the mpt drivers...
>>
>> - - very slow write performace: 'dd if=/dev/zero of=/dev/da0s2  bs=512 
>> count=32768' reports a throughput of 80 k(!)Bytes/s. Read  performance 
>> is somewhat better, 'dd' reports here about 2 MB/s...  better, but not 
>> what I would expect from a RAID1 with two U320 SCSI- disks (Seagate BTW).
> 
> 
> The dd write performance increases with the block size up to approx.  5 
> MB/s with bs=32768.
> Is this normal behaviour?

It should indeed be much faster.  I'd suspect cabling problems.  How 
many drives are on the bus?  Are there any special connectors on the
bus?  Have you looked through the MPT BIOS?  What happens if you slow
the drives down to U160 or slower speeds?

> 
> Further, gvinum is not working with this disk subsystem. If I try to  
> create a gvinum-drive, the drive seems to be created ('gvinum list'  
> reports the drive), but it has the state 'down' and cannot be  started. 
> After a reboot, there's no gvinum-drive at all any more. If  I look at 
> the first sectors of the partition which should contain the  gvinum 
> drive, there's absolutely nothing written to disk, even after  a 'gvinum 
> saveconfig'. All zeroes, no "In VINO" gvinum magic, no  drive size, 
> simply nothing - strange!
> 
> This seems not to be gvinums fault, because gvinum works on all other  
> machines I tried, with conventional SCSI-disks as well as with IDE- 
> (shudder :-) disks. Very strange!
> 

Are you expecting gvinum to integrate with the raid functionality of the
mpt hardware?  If so, my answer is that it simply doesn't work that way.

> 
[...]
> 
> If I try to 'boot -v', the system ends up in an endless loop with the  
> following messages:

Yes, the excessive verboseness needs to be fixed.

Scott


More information about the freebsd-current mailing list