I have some files for which du -h returns 512, my understanding it is supposed to return numbers with units. What does it mean ? What is the actual disk space being used ?

good file

(base) -bash-4.2$ du -h 2020.110/drr0/X1.0060_0958
36K 2020.110/drr0/X1.0060_0958
(base) -bash-4.2$ ls -l 2020.110/drr0/X1.0060_0958
-rw-rw-rw- 1 user11 users 36628 Jul 29 18:43 2020.110/drr0/X1.0060_0958

bad file

(base) -bash-4.2$ du -h 2020.110/drr0/X1.0060_0957
512 2020.110/drr0/X1.0060_0957
(base) -bash-4.2$ ls -l 2020.110/drr0/X1.0060_0957
-rw-rw-rw- 1 user11 users 0 Jul 29 18:51 2020.110/drr0/X1.0060_0957

du never shows units. Notice that in both cases there is no 'B' (for bytes) in the output – the "human-readable" mode only shows multiplier prefixes (K, M, G) but not units themselves. And as there is no prefix for numbers below 1024, none is shown.

Normally 'du' measures files in blocks (see manual page), but with the '-h' option, the unit is always 1 byte. So when du -h shows 512, that's 512 bytes.

Why 512 and not 0? See phuclv's answer

  • Small clarification here, du -h does show units whenever a file is more than 1024 bytes. So it represents bytes as a number, but kB, mB, gB, and so on have units.
    – anonymous
    Jul 31 at 15:37
  • 4
    @anonymous: "36KB" would have a unit (bytes), but "36K" does not – "kilo" is not a unit by itself. 36K is just 36 kilosomething. (Or 36 kelvins but that's clearly not applicable here.)
    – user1686
    Jul 31 at 15:46
  • Ah, my brain assumed that it said kB. On closer inspection, it says K.
    – anonymous
    Jul 31 at 15:53

Files aren't always consuming space on disk. Files with fewer data blocks than the real size will be reported with a smaller number of blocks

  • Sparse files will only have non-zero blocks stored on disk. So a 50TB sparse file with only 5MB non-zero data will consume only ~5MB on disk
  • Inline files will also consume 0 byte in the data area, because they're stored right in the metadata itself. In NTFS it's called resident files and later many other Linux file systems like ext4 or Btrfs also support a similar feature
  • Compressed files also have a smaller number of blocks after compressing

Probably your file is inlined. Since it has no allocated blocks, the number reported by ls will be 0. You can easily check that with stat. In ext4 only files very small compared to the inode size (256+ bytes) can be inlined, so probably you're using another file system like NTFS or Btrfs

You can use the --apparent-size option in du to see the real size


print apparent sizes, rather than disk usage; although the apparent size is usually smaller, it may be larger due to holes in ('sparse') files, internal fragmentation, indirect blocks, and the like


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.