Cooked File system question

My site is using Informix DWS v.7.3 on a Sun 3000 running Solaris 2.6. Our data is stored on an A5000 disk array with 14 drives. We are considering upgrading the SCSI controllers so that we can have redundancy to that device in case one channel (controller or GPIC) is lost. Not all of the chunks were created using symbolic links. I know that the Admin manuals speak of using only symbolic links for raw file systems in the case of controller failure or other hardware changes. Does this appy equally to cooked file systems? In other words if I change the drive controller configuration will the Informix engine still se my chunks/extents? Thanks, Don Bryant

Don Bryant wrote: > > My site is using Informix DWS v.7.3 on a Sun 3000 running Solaris 2.6. Our > data is stored on an A5000 disk array with 14 drives. We are considering > upgrading the SCSI controllers so that we can have redundancy to that device > in case one channel (controller or GPIC) is lost. > > Not all of the chunks were created using symbolic links. I know that the > Admin manuals speak of using only symbolic links for raw file systems in > the case of controller failure or other hardware changes. Does this appy > equally to cooked file systems? Yes. It is always a good idea, while COOKED files are not. > In other words if I change the drive controller configuration will the > Informix engine still se my chunks/extents? Only if the same physical disk space is available at the same path or you backoff and restore the disk to the same path at a different physical location. (This would be an OS level disk partition copy, Informix backups will not help.) Art S. Kagel

Don Bryant wrote: > > My site is using Informix DWS v.7.3 on a Sun 3000 running Solaris 2.6. Our > data is stored on an A5000 disk array with 14 drives. We are considering > upgrading the SCSI controllers so that we can have redundancy to that device > in case one channel (controller or GPIC) is lost. > > Not all of the chunks were created using symbolic links. I know that the > Admin manuals speak of using only symbolic links for raw file systems in > the case of controller failure or other hardware changes. Does this appy > equally to cooked file systems? > > In other words if I change the drive controller configuration will the > Informix engine still se my chunks/extents? > > Thanks, > > Don Bryant Hi, did you know that you can use "raw devices" with your workgroup server, too ? Inserts/Updates/Deletes and every other writing activity will perform faster if you would use raw devices. Sure, raw devices can be supported only if you use the command line utility "onspaces" instead of the graphical command center. But if you are going to change your disk layout, you can try to change the device type as well. onmode -ky ;# shut down your server Copy each chunk: dd if=/yourcooked_file of=/dev/an_empty_new_rawdevice bs=2k count=pages The classic hint "use hard or symbolic links instead of the real pathnames" is a bit overstated. Whenever you must restore a single dbspace the server will restore the data to the pathname stored on the backup tape. If the original pathname is no longer available ( i.e. you exchanged the disk by another one ) the server cannot restore the data to its original path. If you would run into such a situation you should create a link between the new device and the pathname stored on the backup. A "link" can be created whenever you need it. If you used the real pathname you can still create the link before you backup your dbspace from tape. But I agree, it's depressant to create the link together with its chunk. For older versions < 7.3 I would recommend to use "mknod" instead of raw-device links because on some platforms the OS changes the ownership of system files after every reboot. But special files created by your own will not be affected. Newer versions handle chunks even if they do not have the correct ownership or permissions. Best regards, -- Stefan Weideneder Phone: +49 89/3565478-2 --------------- --- Fax: +49 89/3565478-3 ------------- ------ mailto:/stefan@weideneder.de --- -------- http://www.weideneder.de -----