ext4: How to account for the filesystem space?
Let's see. The device size is 1,465,138,583½ kB = 1,500,301,909,504 B. The filesystem consists of 366,284,288 blocks of 4096 B each, which is 1,500,300,443,648 B. I don't know what the remaining 1,465,856 B (1.4 MB) are used for (additional copies of the superblock? I know there are a few kB of space at the beginning for the bootloader.).
The filesystem contains 91,578,368 inodes of 256 bytes each, which takes up 23,444,062,208 B (about 22 GB, hint, hint). Then there is 1,442,146,364 kB = 1,476,757,876,736 B for file contents. This accounts for 23,444,062,208 B + 1,476,757,876,736 B = 1,500,201,938,944 B. The remaining size is 98,504,704 B = 24,029 blocks which is in the right range to be the journal size.
As you can see, everything is accounted for. (Ok, almost everything, but we're talking megabytes, not gigabytes.)
First of all, the difference in available space you are seeing doesn't mean at all that there is space "wasted"; it is not wasted because it is of fundamental importance for the filesystem to function. You should not compare Ext4 and NTFS in this way without a very big "but" specifying all the design and structural differences between filesystems, and also specifics of each implementation (e.g. how each driver reports free space to the VFS layer).
Imagine the partition as a huge space where you can put any pieces of data you have. If you have only one piece of data with a size equal to the partition, you could just write it starting at the beginning of the partition and be cool with it. But you don't. Instead you may have thousands of small files, and all these files grouped in different ways, and each file associated with many other small pieces of data (name, date/time and permissions), etc. You have to organize the big space of the partition so that you can reach all these pieces of data quickly and efficiently. Also, you have to be concerned with how to write new pieces of data and discard old pieces of data efficiently. You need data structures.
And there is a lot of data structures. Some of them are very dumb, others allow you to retrieve data more quickly at the expense of more slower writes, other allow writes more quickly at the expense of reads, some still may be very good at both reads and writes but require long pauses and idle overhead while it rearranges the data, etc.
You certainly want a system that:
- Is very fast to write information on it;
- Is very fast to retrieve information from it;
- Is good at organizing and managing the information stored in it;
- Makes good use of the space (partition) where the filesystem is stored;
- Is resilient against hardware problems, so that you still get most or all your information back on partial system failures;
- Is resilient against software problems, so that a bug in an application, or a malicious application installed, will not destroy your data permanently;
- Is resilient against human errors, so that it forgives you when you accidentally orders the system to delete something you shouldn't (a.k.a. the trash/recycle bin).
High-performance filesystems allow very fast reads and writes at the expense of some space. Some of the fastest data structures used in filesystems, like hash tables and B-trees, are very complex, and they reserve more space than it is actually in use in order to allow very fast accesses.
Ext4 has other important properties. There is no single point-of-failure in the filesystem. There are many copies of critical data spread through the partition, while some other filesystems (I can't say for NTFS) may render all your data unreadable if a failure happens on the right spot. Also, Ext4 reserves a lot of space for your data right at filesystem creation stage, while NTFS grows with your data.