I was very excited to create my first > petabyte (pebibyte actually) single filesystem this afternoon! And sure enough, df -h
reported the size in PiB. I remember filing a bug on df
not supporting terabytes (tebibytes) over a decade ago. Thus, I was slightly surprised to discover that it knows about PiBs.
$ df -h /dev/mss1 /dev/dl1 Filesystem Size Used Avail Use% Mounted on /dev/mss1 1.1P 663T 386T 64% /net/mss1 /dev/dl1 350T 18M 350T 1% /net/dl1
$ rpm -q coreutils coreutils-8.4-31.el6_5.1.x86_64
This made me curious as to how ridiculously large of units df
, dd
, etc. support. It turns out that coreutils
is using a function from gnulib
to do the “humanizing”.
From gnulib/lib/human.h
:
char *human_readable (uintmax_t, char *, int, uintmax_t, uintmax_t);
From gnulib/lib/human.c
:
static const char power_letter[] = { 0, /* not used */ 'K', /* kibi ('k' for kilo is a special case) */ 'M', /* mega or mebi */ 'G', /* giga or gibi */ 'T', /* tera or tebi */ 'P', /* peta or pebi */ 'E', /* exa or exbi */ 'Z', /* zetta or 2**70 */ 'Y' /* yotta or 2**80 */ };
Holy smokes! It supports the entire range of defined SI prefixes. df
is ready to support “yotta-scale” filesystems; that’s a billion PiBs. I think that will hold me over for awhile. 😉 It makes me wonder if we’ll see new SI prefixes defined in my lifetime driven by storage capacities…