[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