File System Development

Some modern filesystems (XFS for one) allocate inodes dynamically as needed. Filesystems without that feature choose an experience-based value relative to disk size (e.g. ext2/3/4 creates 1 inode per 4KB disk space IIRC) and there's usually a way to tune this value when creating a filesystem.

In some Unix filesystems (e.g. ext*fs) that is actually up to the system administrator, who sets a relative parameter while creating the filesystem.

If the filesystem will host lots of small files (news and mail servers are a typical example) you need a large number of inodes, since you need an inode for each object (file or directory).

If, on the other hand, the filesystem will host larger files (e.g. a video server) you don't need as many inodes.

Since inodes take up space, it's important to achieve a balance between performance/efficiency and having enough inodes for your purpose. A simple method is to compute the average file size on an active filesystem with similar usage patterns and use that number as a base value for the bytes/inode ratio on the new FS. That would allow the FS to remain functional while the volume fills up, as long as the usage patterns don't change drastically.

If you are actually designing a new filesystem, rather than just creating a volume, you should consider the idea of allocating inodes dynamically like some other common Unix filesystems (e.g. JFS, XFS, Reiserfs). That would make your filesystem slightly more flexible, although it is generally thought that dynamic FS structures make recovery from corruption problems significantly harder.