10-15-2013 01:37 AM
We ran into a strange problem.
from on day to another the quotas-File in the Filesystemroot increased from 1,2 MB to 128 GB.
This seems to make the response of the repquota command very slow (severeal minutes, which used to be fractions of a second).
Before raising a call at HP-Support I want to make sure that we did not miss something very simple.
We are running HPUX 11.31 on an BL860, Filesystem is on a P2000, and Size of the Filesystem is about 600GB (did not increase very much in the last days)
we already switched the Filesystem over to another node (two nodes in an MC-Serviceguard env), but no luck.
we also tried to move the huge file away, but almostinstantly there was a new file with exact the same size ...
Has anybody had an issue like this ?
Thanks in advance,
10-15-2013 10:46 AM
By any chance, does your system have users with unusually large UID/GID numbers?
Or have you recently specified a disk quota for user "nobody" (typically UID -2... or if interpreted as an unsigned number, something rather big)?
10-16-2013 12:04 AM
thanks for your response.
we have high UIDs/GIDs, but those were working fine for the last years.
UID 38272 and GID 6814 were highest until last week;
we then recently added a User with UID 38292 and GID 6722
I tried also to remove quotas completely using the quotaoff / quotaon / quotacheck command until I figured out that they are no longer supported.
So there might be a chance that I messed all the quotas up :-(
But, this is does not matter very much, because we were using quotas only for a few Users (would be very easy to reconstruct those).
The only thing is: I cannot umount/mount the filesystem, because it is heavily used in an manufacturing environment. And therefore I dont want to mess up the filesystem
10-16-2013 04:19 AM
Those aren't high at all - I was thinking about more-than-16-bit UID values like 4294967294.
(See "id nobody" for an example!)
HP-UX has apparently supported 32-bit UIDs since version 10.20.
A huge /quotas file might actually be a sparse file. Use the "du -k" command to see how much disk space it actually occupies - it might be significantly less than the file size as reported by "ls -l".