I was told by netapps some months ago that their next hurdle in making larger-capacity boxes was the inode cache kept in system RAM, that to increase the inode cache would involve swapping half of it out to disk (which, imho, I can't visualize as working in any nice way whatsoever). So it's OnTap's maintenance of an inode list, rather than the space in a 32 bit int, that's the limitation.

I then go on to speculate that this is one of the main factors causing the nextgen boxes to be so delayed (the SMP problems being the others).

This is, of course, all pure speculation based on imperfect memory of a conversation months ago.

--David Schairer VP/Chief Systems Architect Concentric Network Corp.

On Tue, 19 Oct 1999, Jim McCoy wrote:

...

...

...

2. Inode cost should not be overlooked. You get at most 32 million per

volume, so if you have a lot of mailboxes a maildir or other one-file-per-message scheme will chew through your inode limit long

before

...

...

you run out of disk space on that volume.

BTW, how did you arrive at that number?

Experimentally and asking netapp. It may be that they have increased the max value for maxfiles a while back and I did not notice, but at least up to the early 5.1.2 series 32 million was the most inodes per volume allowed (we ran into this the hard way when trying to use a filer to keep track of user database entries for MyYahoo; it was a very painful experience...)

That is interesting indeed. I couldn't find a mention of this on NOW or NetApp's main site. Perhaps it's there and I simply didn't use the right keywords in the search. As I understand it, modern NetApps use 32-bit inode numbers. This gives us 2^32 inodes. 32 million is roughly 2^25 that is 2^7 times less than alegedly supported by the inode numbers. 32 million is a far cry from roughly 4.3 billion supported by 32-bit addressing. Furthermore the new NetApp hardware is 64-bit which makes far larger addresses possible.

Tom