What is the difference between “inode size” and “Bytes per inode”

Question

Below information is taken from man page,I would like to know the difference between bytes-per-inode and Inode-size?

-i bytes-per-inode

Specify the bytes/inode ratio. mke2fs creates an inode for every bytes-per-inode bytes of space on the disk. The larger the bytes-per-inode ratio, the fewer inodes will be created. This value generally shouldn't be smaller than the blocksize of the filesystem, since then too many inodes will be made.Be warned that is not possible to expand the number of inodes on a filesystem after it is created, so be careful deciding the correct value for this parameter.

-I inode-size

Specify the size of each inode in bytes.mke2fs creates 256-byte inodes by default. In kernels after 2.6.10 and some earlier vendor kernels it is possible to utilize inodes larger than 128 bytes to store extended attributes for improved performance.The inode-size value must be a power of 2 larger or equal to 128.The larger the inode-size the more space the inode table will consume, and this reduces the usable space in the filesystem and can also negatively impact performance.Extended attributes stored in large inodes are not visible with older kernels, and such filesystems will not be mountable with 2.4 kernels at all.It is not possible to change this value after the filesystem is created.

Answer 1

Well, first, what is an inode? In the Unix world, an inode is a kind of file entry. A filename in a directory is just a label (a link!) to an inode. An inode can be referenced in multiple locations (hardlinks!).

-i bytes-per-inode (aka inode_ratio)

For some unknown reason this parameter is sometime documented as bytes-per-inode and sometime as inode_ratio. According to the documentation, this is the bytes/inode ratio. Most human will have a better understanding when stated as either (excuse my english):

• 1 inode for every X bytes of storage (where X is bytes-per-inode).
• lowest average-filesize you can fit.

The formula (taken from the mke2fs source code):

inode_count = (blocks_count * blocksize) / inode_ratio

Or even simplified (assuming "partition size" is roughly equivalent to blocks_count * blocksize, I haven't checked the allocation):

inode_count = (partition_size_in_bytes) / inode_ratio

Note 1: Even if you provide a fixed number of inode at FS creation time (mkfs -N ...), the value is converted into a ratio, so you can fit more inode as you extend the size of the filesystem.

Note 2: If you tune this ratio, make sure to allocate significantly more inode than what you plan to use... you really don't want to reformat your filesystem.

-I inode-size

This is the number of byte the filesystem will allocate/reserve for each inode the filesystem may have. The space is used to store the attributes of the inode (read Intro to Inodes). In Ext3, the default size was 128. In Ext4, the default size is 256 (to store extra_isize and provide space for inline extended-attributes). read Linux: Why change inode size?

Note: X bytes of disjkspace is allocated for each allocated inode, whether is free or used, where X=inode-size.

Answer 2

bytes-per-inode determines how many inodes are created for that file system; inode-size determines how big each of those inode is.

You need a lot of inodes if you intend to put lots of small files (&/or lots of directories) on the filesytem.

AFAIK, you really only need inodes that are larger than the default size of 256 bytes if you want to store extended attributes for your files.

Answer 3

Extremely rough filesystem schematic:

|_|__inodes__|_______________________DATA_________________________________|

• inode-ratio/bytes-per-inode = amount of inodes for the DATA area
• inode-size = size of each inode in the inodes area

Answer 4

I really liked the answer of sjas, it gives the essence of the difference.

This is just my own expansion (as I cannot comment or vote, just starting with this stackexchange) and I wanted an answer for myself stated in a balanced way in non-technical terms understandable to the user who needs to make the decision during data volume setup but not necessarily know all the details behind implementation.

Personas/Objects: - volume(s) of data in storage devices - files in volume(s) - storage devices, they are formatted and provide blocks of bytes and their addresses - locations of files in the storage

Actions : creating/deleting/renaming files and folders by the operating system in the storage, file reads/writes/moves, changes of permissions etc.

File of size of N bytes needs to be created in "chunks" (blocks). Although theoretically one can think that the files could be managed as sequences of single bytes (logically they can) all we would need to manage files in the space would be a designated index telling some file properties (name etc) and where each file starts in the storage. However because of the way the hardware is designed with the "buses" and "blocks" and performance considerations those "chunks" are of particular size, and a multiple of the block size of the media (e.g. 512 bytes, 4096 bytes) and are managed by inodes layer which tells the next layer about files locations and how the chunks are strung together when they need to be found, loaded to memory etc.

If one had one big scroll of paper (volume) and had to design an information storage for documents made of pages (of characters or bits of information) for storing multipage documents what is needed is an index (to find documents), storage space for the pages (with some simple positions of pages). In Unix collation mechanism (inodes) and actual cutting into pages. inode-size is the index entry size (more or less) bytes-per-inode is the page size

Effects of changing the two settings in question:

changin inode-size - usually there is no need to change, stick with the default (as per link posted in previous answer to a discussion)

bytes-per-inode - affects the maximum number of files one can possibly create in the volume (possibly performance and "wastage" of unused bytes)

Going back to paper roll analogy : Imagine having to write and store a document of particular size (a file) in such a system (or many documents of various size)- if the page size, which is presed during the "writing and storage system" definition and not flexible, is very the same document might require many pages, if the "system" page size is very large and the document sizes small then lots of paper could potentially be wasted by having blanks and fitting small files in one page. If the page size is large - there are fewer pages that need to be used for the document but there could be lots of "wasted blank space" in the last page used. So it all depends ... on the size of files that will be used and how many. The other consideration is speed of finding and bringing the document of many pages.

Hope it makes sense (it does for me) and please comment if I have seriously abused any part of ext design or mkfs options.