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.
- 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.