[Info-vax] FREESPADRIFT

Phillip Helbig undress to reply helbig at asclothestro.multivax.de
Sun Jun 12 16:22:24 EDT 2016


In article <njkcgp$u8s$1 at Iltempo.Update.UU.SE>, Johnny Billquist
<bqt at softjar.se> writes: 

> > What causes the free-space count to become wrong?  Since VMS obviously
> > knows about it (otherwise /REPAIR couldn't fix it), why isn't it always
> > correct?
> >
> > Is there any reason not to run ANA/DISK/REPAIR, say, once per day?
> 
> Guessing, based on RSX and ODS-1, the count is kept and updated as files 
> are created/deleted/extended/truncated. However, there is no guarantee 
> that nothing bad happens sometime, that is not reflected in an update in 
> that count. Such as if the system crash while a file system update have 
> not been flushed to disk yet. Or only partially updated.

I can understand it being off if there is some hardware problem, or some 
OS crash, or a program behaving badly.  But I occasionally see it in 
normal operation.

> ANALYZE, on the other hand, actually scans through all disk blocks used 
> by the file headers, and then update the block used bitmap, and block 
> used counts, based on this. So it is updated to become the true, correct 
> count of how things actually are on disk right now.

OK.  With /REPAIR, when it is finished, though, it issues the same 
message as without /REPAIR, i.e. that they differ.

> Reasons not to run it every day? Well, that would be because you need to 
> make sure the file system is not in use when you're running it, since 
> you do not want updates done while ANALYZE is running. Also, it can be a 
> rather CPU and I/O intensive operation to run ANALYZE. So it is 
> inconvenient and disruptive to run it.

It takes a minute or so.  Is it correct that while the disk is locked 
while it is running, nothing actually suffers as a result?

Or, is there a reason to run it at all, as long as there is enough 
usable free space?




More information about the Info-vax mailing list