We're in the process of ordering another filer, this time with 36Gig disks. One think that we'd like to do is cut down on the filesystem overhead.
Just out of curiousity, if we make maxfiles really small (say 50 per meg ) can we we get more available file space? Our current average filesize is ranges from 22k to 89k depending on the actual filesystem.
How much space do netapps 'inodes' take?
----- Stephen C. Woods; UCLA SEASnet; 2567 Boelter hall; LA CA 90095; (310)-825-8614 Finger for public key scw@cirrus.seas.ucla.edu,Internet mail:scw@SEAS.UCLA.EDU
Hello,
The information that you should need to calculate the size of the inode is each inode is 4 bytes but the initial inodes are allocated 1 inode for every 32KB of disk space. In your example you said you have files ranging from 22K to 89K so your inodes might be correctly defined unless your average is
32K.
Also, you should allocate your inodes before writing any information to the volume.
Hope this helps,
Jack Verdirame Zerowait www.zerowait.com ----- Original Message ----- From: scw@seas.ucla.edu To: toasters@mathworks.com Sent: Wednesday, December 08, 1999 3:18 PM Subject: Maxfiles and available space
We're in the process of ordering another filer, this time with 36Gig disks. One think that we'd like to do is cut down on the filesystem overhead.
Just out of curiousity, if we make maxfiles really small (say 50 per meg ) can we we get more available file space? Our current average filesize is ranges from 22k to 89k depending on the actual filesystem.
How much space do netapps 'inodes' take?
Stephen C. Woods; UCLA SEASnet; 2567 Boelter hall; LA CA 90095;
(310)-825-8614
Finger for public key scw@cirrus.seas.ucla.edu,Internet
mail:scw@SEAS.UCLA.EDU
The information that you should need to calculate the size of the inode is each inode is 4 bytes ...
No. An inode number is 4 bytes (a 32-bit unsigned integer), but inodes are 128 bytes. So, 128*maxfiles is how many bytes will be occupied by the inode file.
... the initial inodes are allocated 1 inode for every 32KB of disk space.
I believe that's correct.
Also, you should allocate your inodes before writing any information to the volume.
Why? It sounds like you're trying to keep the inode file contiguous. I'm not sure if the blocks of the inode file are actually allocated when you create the volume, or increase maxfiles, but even if they are, the very design of WAFL will move each one as soon as something within it changes.
One of the beauties of WAFL is that you *don't* need to decide how many file you'll need when you initialize the volume -- if you start to run low, you can increase maxfiles whenever you like. (You cannot decrease maxfiles, though, so it's best not to be too aggressive.)
The only real consideration is that you don't want the number of free inodes to get too low, especially if you have (or expect to have) a large number of directories. When creating directories, WAFL tries to spread their inodes throughout the available inodes. When creating a file, WAFL attempts to use an inode that is in the same block as the directory's inode, or at least close. If there aren't many free inodes, this strategy won't succeed, rendering it more likely that accessing the file will require reading an extra block of the inode file. Creating the file in the first place will be slower, too. You don't have to increase maxfiles before writing any information, though, just when you start to run short of inodes.
-- Karl Swartz Network Appliance Engineering Work: kls@netapp.com http://www.netapp.com/ Home: kls@chicago.com http://www.chicago.com/~kls/