Delayed Volume Statistics

[Kenneth Winders]

We have TRU64 5.1b running on an ES40 cluster (2 nodes) with a memory channel interconnect.
Recently a volume exceeded 90% utilization and we removed some files to clean this up. We were logged into node 1 and it showed the file deletion immediately and reported the reduced utilization. However, it took over 4 hours for this to be reflected on node 2. Has anyone experienced this same event? Any suggestions on what may be happening here?

Thanks, Ken

[Hein van den Heuvel]

I assume you are using CFS as the file system, and DF to check the space availability?

I mentioned this problem description to a CFS devo and she does not understand how this could happen. Specifically she assures me that 'df' never used cached information and always goes to the server (owning node) of the filesystem to get the scoop.

The only time a temporary (30 seconds) discrapency might occur is due to a notion of reserverations versus allocation. A client may have already reserved space, but not yet allocated to a file. In that case there is less space available then currently reported (not more as in your case). Reservations help reduce round-trips and significantly increase performance for growing files.

Can you provide further details on the problem? like which node was client, which server (cfsmgr)? What tool used to show space (df?)? How does cross-checking with other tools (du) work out? How much was freed up, but in % and in MB/GB? Sparse files in the picture?

If this is repeateable and remains unexplainable, then you may want to formally report this as a problem to support, as while it might just be a curiosity to you today, it may be critical at an other time for an other user.

fwiw,
Hein.

[Kenneth Winders]

Thanks, Hein.

Your first assumption was correct. I haven't investigated it any more, as you said, for me this was just a curiosity right now.

You do raise an interesting point about it being a problem for others. We'll try a few things and then post what we've done and found.

Thanks again. Ken