Conference vaxaxp::vmsnotes

Hi,

It is a normal shutdown, no error message display.

The customer use ANALYZE/DISK/REPAIR/CONFIRM.  After my suggestion, the customer
run the command interactively once, message display and repair it.

There are no more message display until now even they analyze the disk again.

Thanks for your help.

    This may be obvious, but you might wanna check that theu are running
    quotas on the disk. (no /noquo on the mount command) ?

Hi,

Thanks for your help.  When they mount the disk, it was only mount/system, 
without any quota qualifier.  

Now the customer analyze the disk before every shutdown.  According to the
customer, the message will sometimes display (most often).  Everytime, 
the customer will type yes to repair it.

Actually, I am not quite familar with the analyze disk mechanism.  Why
does the message always display even we repair it?  Any problem with the
disk itself?

Kenneth Leung
    

    So, by extension doing the following:
    
    $ anal/disk/repair Dcuu:
    $ dismount Dcuu:
    $ mount/sys Dcuu:
    $ anal/disk/repair
    
    Will cause errors to be reported during the *second* repair ?  If that
    is the case then ANAL/DISK has a bug.
    
    If this works OK, then we have to assume that something else is going
    on while the machine is shut down.  IS the disk mounted in a cluster ?
    Is it the system disk ? (I don't think quotas are supported on system
    disks) Are there any 3rd party caching products running in the cluster?

    
    First, what problem is the customer trying to solve?
    
    Second, the enabling of quota on the system disk is very dumb indeed.
    
    It slows systems down and, although supported, will cause all kinds of
    problems.
    
    Files on the System disk are very volatile, especially through boots.
    It's not at all suprising that this causes odd messages.
    
    /a

Hi,

The customer use the analyze/disk as a management tools to check against
the file consistence on the system disk.  They issue the same command
on the system disk before they upgrade from VMS V5.5-2 to V6.2.  There is
no such message on VMS V5.5-2.  That's why the customer stress that there may
be something wrong after the upgrade.

Kenneth

   Has the customer considered that there may have been something wrong
   *before* the upgrade, and that things are now being correctly handled?

   These errors are not normally particularly serious errors -- disk
   quotas have been known to skew, and many of the ways the disk quotas
   have drifted have been repaired over over the years.  (And there have
   been a number of quota-drift-related notes discussions occuring over
   the years, as well.)

   I'd take a serious look at what applications were running when the
   system crashed, or when the system was shut down.  If the system
   crashed or was hard-halted or the power failed, then there is a
   reasonable chance that the disk quotas will be skewed somewhat from
   actual usage -- the active disk quotas are kept in memory for reasons
   of performance, and are flushed out to disk.   The ANALYZE command
   fixes a skew between the in-memory value, and the quota value that
   was last flushed out to disk before the system went down.
 
   No quota information is lost.

   If your customer is interested in some of the details of disk quota
   processing, please suggest they acquire a copy of _VMS File System
   Internals_ from Digital Press.

   If your customer would like this situation looked at formally -- given
   how long this question has been under discussion here, I hope this is
   not a `hot' customer question -- please log a QAR or an IPMT.  (I'd
   use a low-priority QAR or IPMT, as this looks more like a `customer
   comfort upgrade' call than an actual problem.  :-)