Brian Tao wrote:
On Thu, 20 Nov 1997, Kenneth Whittaker wrote:
Discrepency between du and df on an empty filesystem. I suspect that it is the meta-data files. There are invisible files that hold information about the filesystem.
New information: I bumped up the maxfiles on all four filers to2.5 million inodes. The adm1-na1 and adm1-na4 both printed the warning about having more than twice as many files as needed, but adm1-na2 and adm1-na3 did not. However, after all four were set to 2.5 million files, the df did not change (trying after umounting and remounting the filesystems, rebooting the filers, etc.).
That is correct. Because, when you increase maxfiles, a big hole is stuck at the end of the appropriate meta-data files. A hole, as some people will agree, consumes no blocks.
Try this from a Solaris box running perl: Check your "df" ouput.
(create 100,000 files in an empty directory) perl -e 'for($i=0;$i<100000;$i++){open(F,">$i")}'
(delete the files) perl -e 'for($i=0;$i<100000;$i++){unlink($i)}'
You just filled in a bunch of holes. Now check your "df" output.
As I said previously, maxfiles on the filers should have beenidentical, assuming that previous maxfiles settings are lost when the filesystem is wiped clean and recreated. I'm going to wipe everything out again after the latest rounds of tests, and I'll try to reproduce this condition.
maxfiles does not explain away anything, and I don't believe maxfiles has anything to do with this problem whatsoever. I have heard people mention maxfiles in association with this problem, but I have ignored it thus far.
|| admin# df -k /na1 /na2 /na3 /na4 || Filesystem kbytes used avail capacity Mounted on || adm1-na1:/ 33007568 4520 33003048 1% /na1 || adm1-na2:/ 33007568 40192 32967376 1% /na2 || adm1-na3:/ 33007568 40184 32967384 1% /na3 || adm1-na4:/ 33007568 4408 33003160 1% /na4
-- Brian Tao (BT300, taob@netcom.ca) "Though this be madness, yet there is method in't"