Conference smurf::ase

    re .0
    >you can't newfs /dev/vol/dg1/vol01 rz1bb
    
    Shouldn't that be /dev/rvol/dg1/vol01 i.e. the character special device
    instead of the block special?
    
    Maybe this is just my way of thinking. I went to the dxlsm Options pull
    down menu, Show Command, Show at Start and created a small volume
    checking the Usage type: fsgen and Create file system: Yes toggle
    buttons. The Command Info Window listed the commands that dxlsm
    issued for me. Every time I have been doing this I get something like:
    
    	volassist -g dg1 -U fsgen make vol01 256m   DONE
    	newfs -s 524288 /dev/rvol/dg1/vol01 rz26    DONE
    
    So dxlsm uses rz26 as disk type no matter what the disks look like the
    volume is based on. At this point I decided: why should I bother trying
    to use anything different when manually creating a UFS on top of a
    volume. Well maybe this question is better asked in AOSG::LSM.
    
    	Martin

    
    re: -.1
    
    I swapped out the rz1bb-cs drives for rz28d-vw's and newfs worked like
    it should on Fast10 disks. I then was able to add the service and get
    further into my configuration testing when I am supposed to modify the
    service (after it was started). With the rz1bb-cs disks newfs'd as
    rz28's I could not get beyond the point where it asks what I wanted to
    modify (/dev/vol/dg1/vol01   ( UFS ) option). I believe this is still
    related to the initial notes failure. Since the drives (rz1bb-cs) are
    labeled as such and newfs'd as rz28's I think it confused ase even more
    so (or whatever command was invoked at that time).
    
    This can be (and has been) duplicated as I did this to rz1cb-cs drives
    as my mirror set and newfs wouldn't work on them till I told it to use
    rz29b as the type of disk, which I did to alleviate the possibility
    that it was these particular disks. I am not sure where I will QAR this
    other problem since I am not sure if it is ASE/LSM/NEWFS issue here or
    a DDR (Dynamic Device Recognition) issue.
    
    

Some questions & Suggestions :-
1) Does /etc/disktab have a reference for the real disk you are using ?

2) As most entries in the disktab file relate to drives with FIXED Geometry
   have you tried using types that by definition are of variable Geometry
   such as HSZ40 connected type  SWXCR ? You may also have to play around
   with the disklabel as well.

3) As a possible fix, update the disktab file and choose a supported drive 
   type that is not likely to be found on the system and modify its entry to
   include the partition table of the ultra-SCSI drives. Then you can call
   your new drive something else and possibly get away with it. I did this
   years ago when we were developing a driver for a special 3.5" floppy on 
   a VAX ULTRIX box (Ultrix V1/V2 days). I ended up modifying an existing 
   device partition layout in disktab to get newfs to work properly.  

Regards,
	Stephen Davies

    
    Hi Stephen,
    
    1) Does /etc/disktab have a reference for the real disk you are using ?
    
    No, these are new devices and V4.x uses DDR now. There are some entries
    in the disktab file, but not for anything relatively new.
    
    2) As most entries in the disktab file relate to drives with FIXED
    Geometry have you tried using types that by definition are of variable
    Geometry such as HSZ40 connected type  SWXCR ? You may also have to play
    around with the disklabel as well.
    
    Not yet, but I have been tasked to add an HSZ70 into the picture when I
    have time. Not sure whether I will run that in conjunction with LSM as
    I am not sure how I would configure it and not sure if CXO has done
    this already/configured one with LSM.
    
    3) isn't a good thing because this will impact customers who will be
    buying ULTRASCSI disk drives, and not necessarily from us. This is good
    for hacking around to get something to work (as you stated to get
    something to work properly, did it make it into the file later on as a
    more permanent fix?).
    
    I tried an RZ1DB-CA (Atlas2 ULTRASCSI 9Gb) and had no luck newfs-ing it
    as either itself or as an RZ40-AA which is the narrow 9Gb version of an
    ULTRA NARROW disk which is being locked down to Fast10 mode as we are
    not selling ULTRA Narrow disks. I am now going to try an RZ1CB-CA which
    is the 4Gb version and if its name doesn't work (as expected) I will
    try it as a comparable RZ29B and then go into the process of adding in
    as an NFS service and see if it fails when I go to modify the service
    after it is added. That is where the UFS issue comes into play after
    telling the system it's an RZxx(x) disk when in fact it is ULTRA and
    the disklabel shows that info.
    
    I am not sure why modifying the service is not working on UFS other
    than the assumption that whatever is going on in the background is
    looking possibly at what is REALLY is (ie reading disk label or doing
    an inquiry to the device) and comparing that to what may be in memory
    or how it was newfs'd. That is my best guess. This is definitely a
    very HOT issue customer-wise who want to full ULTRA capability with
    KZPBA-xx, F20 DOC module in new BA356 ULTRA shelfs (coming soon), 180w
    power supplies (for ULTRA shelfs) and then the storage medium of ULTRA
    disks!  The newfs bug has been QAR'd but I am trying to determine if
    this is a related issue (failing to modify the service) before I add
    info to the current QAR or create a new one.