[Info-vax] FREESPADRIFT

[Johnny Billquist]

On 2016-06-12 22:22, Phillip Helbig (undress to reply) wrote:
> 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.

That would sound more like a bug in that case.

>> 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.

That's the same in VFY under RSX then. In RSX it is because the report 
gives the information as it was before the repair was done. If you run 
it one more time, the numbers should stabilize, I would think.

>> 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?

A minute? Really? Wow. That sounds like a much more light weight operation.

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

As long as it only misses in that it reports less free than is the 
actual case, then it's not that important. But at least in RSX, the 
errors can also go in the other direction, so that you have blocks that 
are in use, which the system also consider to be free. If those are not 
taken care of, you can end up with the same disk block being allocated 
to two files, causing data loss and strange corruptions. Not a good thing.

In essence, there are two different structures that keep track of 
allocated blocks, and when they don't agree, something is wrong.

One is the BITMAP.SYS file, which keeps track of all free and allocated 
blocks on the volume. The other is the INDEXF.SYS file, which keeps 
record of all blocks allocated to files. If these two sources of 
information disagree, then you have a potential problem coming up.
And figuring out what/where the problem is requires scanning through all 
the blocks allocated to files in INDEXF.SYS, and check that against the 
bitmap in BITMAP.SYS, to find discrepancies, as well as doubly allocated 
blocks to several files. Which is why a run of just a minute or two 
sounds impressive. It can be a lot of data. Now, PDP-11s aren't exactly 
the speed of Alphas, but analyzing a 1G disk under RSX can take hours...

	Johnny