Many disks have a sector size of 512 bytes, meaning that any read or write on the disk transfers a whole 512-byte sector at a time. It is quite natural to design filesystems where a sector is not split between files (that would complicate the design and hurt performance); therefore filesystems tend to use 512-byte chunks for files. Hence traditional utilities such as ls
and du
indicate sizes in units of 512-byte chunks.
For humans, 512-byte units are not very meaningful. 1kB is the same order of magnitude and a lot more meaningful. A filesystem block (the smallest unit that a file is divided in) actually often consists of several sectors: 1kB, 2kB and 4kB are common filesystem block sizes; so the 512-byte unit is not strongly justified by the filesystem design, and there is no good reason other than tradition to use a 512-byte unit outside a disk driver at all.
So you have a tradition that doesn't have a lot going for it, and a more readable convention that's taking on. A bit like octal and hexadecimal: there isn't one that's right and one that's wrong, they're different ways of writing the same numbers.
Many tools have an option to select display units: ls --block-size=512
for GNU ls
, setting POSIXLY_CORRECT=1
in the environment for GNU df
and GNU du
to get 512-byte units (or passing -k
to force 1kB units). What the stat
command in GNU coreutils exposes as the “block size” (the %B
value) is an OS-dependant value of an internal interface; depending on the OS, it may or may not be related to a size used by the filesystem or disk code (it usually isn't — see Difference between block size and cluster size). On Linux, the value is 512, regardless of what any underlying driver is doing. The value of %B
never matters, it's just a quirk that it exists at all.
Best Answer
You won't be able to get such a list, at least not without low-level tools that are specific to each filesystem type and which are normally intended as debug or emergency repair tools.
Filesystems simply don't have any API for querying or listing free/unused inodes. Many filesystem types don't even have the concept of a fixed number of extant inodes on the filesystem, but rather create them on demand.
The best you will get is
df -i
, which produces a count of how many inodes are available (if that makes sense for the filesystem type), but you cannot enumerate them.