[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference cookie::aim$notes:disk_defrag

Title:	Disk File Optimizer (DFO) for OpenVMS
Notice:	Kits and documents: last reply to note 1
Moderator:	COOKIE::AMEND

Created:	Tue May 16 1989
Last Modified:	Fri Jun 06 1997
Last Successful Update:	Fri Jun 06 1997
Number of topics:	539
Total number of notes:	2544

538.0. "DISKEEPER VER 7.0 AND VMB.EXE PROB!" by ALBANY::PEPLOWSKI (Paul Peplowski (Peppy) Albany N.Y. dtn:344-7228) Wed May 28 1997 10:23

    HI:
    
    	I have a customer who just upgraded from HSC style disks to HSJ
    style disks. The customer is running a three member controller based
    raid set as his system disk, when we installed the new disks we had
    problems booting from this raid set. First we thought that we did the
    backup of the data wrong so we did a backup from the original disk to
    tape and then to the new disk from that tape. The system booted and we
    started to install new license packs as we also upgrade a 6510 to a
    7710 this took about an hour all this time diskeeper ver 7.0 was
    running and when we went to do a reboot the boot would fail! We called
    support and they had us do a write boot to the disk and this seems to
    have fixed it. We disabled the diskeeper and had the customer call
    diskeeper who sweares that there is nothing wrong with there product!
    Does anyone know if there are any problems? The customer is running ver
    6.1 of VMS and ver 2.7 of the HSJ software. Any input would be greatly 
    appreaciated.   
    
    						Thanks in advance
    
    						Paul Peplowski ALO
    						DTN:344-7228

T.R	Title	User	Personal Name	Date	Lines
538.1	Use Disk File Optimizer	COOKIE::AMEND		`Thu May 29 1997 09:12`	6
	If the customer was running Digitals Disk File Optimizer then they would not have this problem. thanks jim amend
538.2	BUT IS THERE A PROBLEM??	ALBANY::PEPLOWSKI	Paul Peplowski (Peppy) Albany N.Y. dtn:344-7228	`Thu May 29 1997 13:02`	9
	Jim: is this a known problem with diskeeper??? the customer wants to know... thanks again Paul
538.3		SSDEVO::DESKO	Rick in Storage - DTN 522-3905	`Thu May 29 1997 15:05`	6
	> is this a known problem with diskeeper??? the customer wants to > know... Then the customer needs to work with Executive Software. Rick
538.4	DFO is the defragmentor to go with	COOKIE::AMEND		`Fri May 30 1997 09:43`	16
	Paul Since I put my two 1/2 cents in I feel I have to respond since you named me by name. I have no ideal if this is a particular problem with Diskeeper. I do not know of any problems with Diskeeper other than I never could get Diskeeper to run on my system. I was going to tell you that it was a problem and you should get the customer to switch to DEC's Disk File Optimizer (DFO). DFO is something I support and can answer questions on. thanks jim amend (DFO Engineering)
538.5	I STILL NEED ANSWER.....	ALBANY::PEPLOWSKI	Paul Peplowski (Peppy) Albany N.Y. dtn:344-7228	`Fri May 30 1997 16:02`	22
	Hi this is paul again: The customer wants us "DIGITAL" to come up with a position on wether this product has a problem or not he has already gone to the vendor and they swear they have no known problems! If we cannot explain to the customer that it is a DISKEEPER problem then they want to put it back on and if they have a problem then blame it on the new disk farm and HSJ's. I would like to avoid all of that with an answer from someone in the know....... Any other input would be great. Thanks again Paul Peplowski ALO DTN:344-7228
538.6		CSC64::BLAYLOCK	If at first you doubt,doubt again.	`Fri May 30 1997 17:18`	41
	If running WRITEBOOT fixes the problem, then some peice of software is moving VMB.EXE. So how do you determine this? After running WRITEBOOT, perform a DUMP /HEADER /BLOCK=COUNT=0 SYS$SYSTEM:VMB.EXE and this will give you the LBN location of VMB.EXE on that volume. Map area Retrieval pointers Count: 87 LBN: 908106 It is this number that is recorded into the boot block of your system disk $ x = 908106 $ ss x X = 908106 Hex = 000DDB4A Octal = 00003355512 Dump of file SYS$SYSDEVICE:[000000]INDEXF.SYS;1 on 30-MAY-1997 16:04:57.39 File ID (1,1,0) End of file block 21442 / Allocated 21444 Virtual block number 1 (00000001), 512 (0200) bytes 11002211 00000000 DB4A000D 010C1101 ......J�.....".. 000000 --------------------^ ^ Low ordwer word ^ ------------^ High Order Word It is when these two items do not match that the boot process fails. File system optimizers, such as Diskkeeper and DFO place files by moving a files location (LBN) on the disk. DFO explicitly excludes the LBN in the boot block from being moved. Since DIGITAL did not write Diskkeeper, it cannot know or make a statement to the effect that diskkeeper moved this file or did not do so. Diskkeeper can keep a log of the files that ir moved; enable that and determine if it has been moved. Also, place a security alarm ACL on VMB.EXE and verify what is moving the file.
538.7	Thanks!	ALBANY::PEPLOWSKI	Paul Peplowski (Peppy) Albany N.Y. dtn:344-7228	`Sat May 31 1997 06:58`	11
	Hi this is paul again: Thanks i'll give this a try I really appreciate the input! I'll update after Paul....
538.8	THE FIX IS THERE IS NO FIX!	ALBANY::PEPLOWSKI	Paul Peplowski (Peppy) Albany N.Y. dtn:344-7228	`Thu Jun 05 1997 14:04`	21
	Hi this is paul again: I logged and IPMT case with support and after it was moved from one group to another and landed in VMS support the answer was basically what note .6 said to try well I did all that was in the note and found that the customer was not having VMB.EXE moved by the diskeeper but was getting corrupted somehow. We ran diskeeper on the system over one night and looked to see if the LBN was changed and it wasn't but you could not boot either system!! they would both machine check on boot and the only way to fix the problem was to do a write boot which fixed the problem. So the answer is not to run diskeeper on the system disk even though Diskeeper swares there is no problem... Thanks for all of the input Paul