Linux – How to calculate proper amount of inode/block sizes for a linux filesystem

Firstly, you can't simply add up the sizes of all the files on the disk, and expect that to be the total amount used. Every time you store a file, there is some space wasted. It's like putting books on a shelf, if the books vary in size, then you're going to have a space between the top of the book and the bottom of the next shelf.

Secondly, if you have any files which are open but deleted, then the space that is used will still be used until the program with that file either closes it, or exits. That's often used for temporary files, the program doesn't have to worry about cleaning them up, all it needs to do is open a file, then delete it, before working with it. These files used space will show up in df, but you can't find a filename which corresponds to it. If you want to find them, then you'll have to look in /proc/*/fd

Thirdly, and this is your issue here, ext3 file systems have a percentage of reserved space which can only be written to by root. There are two reasons for this, many file systems become inefficient when the disk becomes close to becoming full, the system has to spend more and more time fitting files into the spaces that are left. Also reading and writing to the files is slow, as they end up being badly fragmented. Another reason for reserving space for root is that it allows root to compress files and hopefully recover some space for the users. If the disk was totally full, then that wouldn't be possible.

Therefore, there is nothing wrong, what you are seeing is normal behaviour for a full disk.

You can't change it in place, as far as I know. You may be able to do it without finding another Tb drive to copy the data to while you rebuild the filesystem by a round-about method:

1. shrink the current filesystem as small as it will go and drop the length of the partition accordingly
2. add a second partition in the newly freed space
3. mount both, and move as much over to the new partition as you can
4. shrink the first partition again, move the new one down the disk and grow it to fill the drive and repeat step 3
5. you might need to repeat step 4 once or twice more depending on how full the original filesystem was to start with

You can do all the above manually with fdisk, resize2fs and related tools, or with parted which is available in most distribution's repositories and as a Live CD. gparted it probably the safest option by far unless you are very familiar with the manual tools already.

But major filesystem move/resize operations like these are the sort of thing I always take good backups before starting, because if anything goes wrong you could kill everything on the affected filesystem(s). So if you are healthily paranoid the above does not remove the need to find somewhere to copy the data too while you reformat/rearrange... Though if most of the data is replaceable, by re-downloading music/video content and such, you could backup the most important stuff and take a chance with the rest.

As an alternative to reformatting/rearranging the drive now you could run a small Linux VM (with vmware or vbox), attach the USB drive to that, and have it share the data to the host (Windows) OS via Samba. This is inefficient and less convenient, of course, but may well be efficient enough "for the time being" until you sort or more permanent solution like buying a new drive to reformat and move everything onto and it is certainly safer than massive filesystem operation on data that you do not have backed up. You do not need to allocate much resource to the VM, I'm guessing a server install of Ubuntu or a base install of Debian would happily run such a Samba share in 128Mb of RAM or less and would not need much more than a single Gb of disk space (in fact, it may only take a couple of hundred Mb, if that) on the host machine.