Someone has just come up to me and asked me:
"What is the maximum number of files on a fully populated (disk wise) F760?"
I don't (sorry) know the volume configuration specified.
have you guys got any ideas?
I couldn't find the maximum value of the maxfiles command documented in the now site, or on my piece of paper from NTAP201/2.
regards,
Kelvin Tooth
Kelvin, Initially, the maximum number of files on the filer is set at one for every 32 KB of disk space. The number is increased automatically when you add a new disk. The increase is determined by the filer, and is not a user-specified value.
Unlike UNIX, which requires that you specify the maximum number of files in a file system when you create the file system, the filer enables you to use the maxfiles command to increase the number of files for each volume at any time.
I believe the max number of files you can set maxfiles to is 1 file for every 4KB of disk space. I don't have access to a maxed out F760 to do the math for you. Hope this helps
Paulb
-----Original Message----- From: owner-dl-toasters@netapp.com [mailto:owner-dl-toasters@netapp.com]On Behalf Of kelvin tooth Sent: Monday, August 14, 2000 8:55 AM To: toaster Subject: Quick question
Someone has just come up to me and asked me:
"What is the maximum number of files on a fully populated (disk wise) F760?"
I don't (sorry) know the volume configuration specified.
have you guys got any ideas?
I couldn't find the maximum value of the maxfiles command documented in the now site, or on my piece of paper from NTAP201/2.
regards,
Kelvin Tooth
"kelvin tooth" kelvin@cwci.net asked:
Someone has just come up to me and asked me:
"What is the maximum number of files on a fully populated (disk wise) F760?"
I don't (sorry) know the volume configuration specified.
have you guys got any ideas?
I couldn't find the maximum value of the maxfiles command documented in the now site, or on my piece of paper from NTAP201/2.
Paul W. Brosseau" paulb@netapp.com> replies:
Initially, the maximum number of files on the filer is set at one for every 32 KB of disk space. The number is increased automatically when you add a new disk. The increase is determined by the filer, and is not a user-specified value.
There is also (in 5.3.x) a limit of 33554432 (2^25) inodes to the minimum placed on maxfiles, or so the start.pdf files say. (See the "Changes to the System Administrator's Guide" section, under "Limit on maximum number of files".)
Unlike UNIX, which requires that you specify the maximum number of files in a file system when you create the file system,
Generally that's only true of filing systems based on the BSD ones; there are many others available these days (e.g. Veritas). It's rather tendentious to refer to this as a restriction of "UNIX".
the filer enables you to use
the maxfiles command to increase the number of files for each volume at any time.
I believe the max number of files you can set maxfiles to is 1 file for every 4KB of disk space. I don't have access to a maxed out F760 to do the math for you. Hope this helps
I tried this out on a 1p+1d test volume (I've no desire to wreck my production systems by increasing their maxfiles values unnecessarily!) and this indeed seems to be the current rule (in 5.3.6). The various fudge factors of 0.9 and 0.95 confuse things a bit: I believe the actual constraint imposed is
(real-diskspace)/32768 <= (real-inodes) <= (real-diskspace)/4096
where
available space (sum of "kbytes" for active file system & snapshots in "df" output) = 0.9 * (real-diskspace);
maxfiles value = 0.95 * (real-inodes).
[real-diskspace is the raw disk space after right-sizing and removing an extra 20.5 MB (iirc); real-inodes is how big inode numbers can actually get. The 0.9 and 0.95 are accurate to several significant digits.]
Anyway, on to the reason I used this excuse to post... :-)
It seems to me that the minimum constraint placed on the maxfiles value is too large (and maybe the new 2^25 cutoff is a partial recognition of this). There are many situations where the average file size in a volume vastly exceeds 32 KB, and the inode table is forced to be unnecessarily large. This does affect the efficiency of some operations; notably "quota on" (luckily one doesn't often have to do that these days) and the planning phases of "dump".
Chris Thompson University of Cambridge Computing Service, Email: cet1@ucs.cam.ac.uk New Museums Site, Cambridge CB2 3QG, Phone: +44 1223 334715 United Kingdom.