Getting block size via df vs dumpe2fs

Question

These two tools, seems to report different block sizes

root@ubuntu-xenial:~# df
Filesystem     1K-blocks     Used Available Use% Mounted on
udev              498588        0    498588   0% /dev
tmpfs             101584     3116     98468   4% /run
/dev/sda1       10098468  1438288   8643796  15% /
tmpfs             507916        0    507916   0% /dev/shm
tmpfs               5120        0      5120   0% /run/lock
tmpfs             507916        0    507916   0% /sys/fs/cgroup
vagrant        343946960 55977016 287969944  17% /vagrant
tmpfs             101584        0    101584   0% /run/user/1000

root@ubuntu-xenial:~# dumpe2fs /dev/sda1 | grep -i block | grep -i size
dumpe2fs 1.42.13 (17-May-2015)
Block size:               4096
Flex block group size:    16

What is more, fdisk command reports different sector size (aren't the terms sector and block interchangeable?)

root@ubuntu-xenial:~# fdisk -l
Disk /dev/sda: 10 GiB, 10737418240 bytes, 20971520 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x38d40272

Device     Boot Start      End  Sectors Size Id Type
/dev/sda1  *     2048 20971486 20969439  10G 83 Linux


Disk /dev/sdb: 10 MiB, 10485760 bytes, 20480 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

I am on a vagrant machine for what that matters

Answer 1

You don't "get block size via df". That's not shown in the output at all.

df lists all filesystems, their usage and mountpoints in one list - and the values shown simply refer to sizes (total / used / available) and not other individual properties like filesystem type, blocksize, etc.

By default, the unit to represent size is 1K-blocks, you can change it to 1M-blocks or 1G-blocks or variable (human-readable).

$ df
Filesystem               1K-blocks       Used Available Use% Mounted on
/dev/dm-34                25155584   19811668   5343916  79% /

$ df --block-size=M
Filesystem              1M-blocks     Used Available Use% Mounted on
/dev/dm-34                 24566M   19348M     5219M  79% /

$ df --block-size=G
Filesystem              1G-blocks  Used Available Use% Mounted on
/dev/dm-34                    24G   19G        6G  79% /

$ df -h
Filesystem               Size  Used Avail Use% Mounted on
/dev/dm-34                24G   19G  5.1G  79% /

(Note the subtle difference -BG and -h is that Available column shows 6G vs. 5.1G. Human-readable size adapts according to size, vs. there is no fraction blocks when using a huge blocksize).

As for the filesystem, it does not have to work in 512 byte units just because the storage device does. Never mind that a lot of storage has larger sectors these days, but still pretends to be 512 bytes for compatibility reasons.

aren't the terms sector and block interchangeable?

Unfortunately, these terms are used in different ways depending on context.

Answer 2

... reports different sector size (aren't the terms sector and block interchangeable?)

"Block" has been used to mean many different things. You have to look at the specific context.

df stretches this further, saying "1K-blocks" to mean units of 1 Kilobyte, even when the filesystem(s) use different block sizes.

"Sector" originally means the block size a disk uses. But notice your fdisk reports two different types of sector size, "physical" and "logical" :-). So you need to look out for context here as well. [*]

What is the filesystem block size?

Because the first tools you mentioned were df and dumpe2fs, I guessed you might be looking for the filesystem block size. In that case, you want the value which dumpe2fs shows as "Block size".

dumpe2fs is a specific tool for ext2/3/4, but I think that makes for the most robust approach. That said, it means that if you use a different filesystem, you will have to use a different tool and confirm exactly what it uses for "block size".

There may be some exceptions to the normal filesystem block size. Very recent ext4 may support data storage inline in the inode. That is, files smaller than a certain size may be stored in the file's inode, without allocating any data blocks at all. See How to use the new Ext4 Inline Data feature ? (storing data directly in the inode)

Alternative query method: statvfs()

Alternatively, you could run stat -f / to show the statvfs() information for your root filesystem. It was discussed here: stat file system sizes.

stat -f output includes two different fields, "Fundamental block size" and "Block size" :-).

The "fundamental" block size is the granularity that space usage is reported in - this will apply to df. You can hope that this is the same granularity used to allocate file space. At least this is true for your ext2/3/4, and in many other cases.

stat claims the other block size is to be used "for fast transfers". In ext2/3/4, these two block sizes will always be the same.

If ext2 had ever implemented fragments, like UFS from BSD UNIX, it would have been possible for the two sizes to differ. This is reflected in dumpe2fs always showing a "Fragment size" value equal to "Block size". See What can f_bsize be used for? (Is it similar to st_blksize?)

As a more generic tool, stat -f is liable to mislead in some cases.

It is not very widely used either; this might increase the risk. It doesn't help that it reports two different values, where the original meanings are not relevant to native Linux filesystems. FWIW, this site's users hated my question asking to confirm its behaviour (the link above). I usually assume this means they got angry because no-one knows how to answer the question.

stat -f is a feature of GNU coreutils. (It is not supported by stat from FreeBSD 7.2).

Is "block size 'for fast transfers' " meaningful?

This description may be relevant for filesystems which implement fragments. If they do not implement "delayed allocation", it may be more efficient to make sure you use a block-sized write buffer when you increase the length of a file. As always, if you are thinking about making a change to improve performance, you should aim to confirm the improvement with measurements.

On Linux filesystems, the two block sizes will be the same value. In this case, I don't know any reason to use that particular value for optimization.

Most often, userspace doesn't have to worry too much about sizing I/O calls "for fast transfers". The IO scheduler can coalesce adjacent I/Os for efficiency. And un-synced IO through the page cache gets massive performance benefits from write-back caching and automatic read-ahead. You can go a long way just using the page cache size, or hard-coding 4KB :-).

In most transfers, the page cache imposes a minimum size for the physical IO. The page size is 4KB on most systems, and usually file IO goes through the page cache. (Again small files are a special case. Or rather the last page of a file is a special case, if the file size is not an exact multiple of 4KB).

---

[*] E.g. given modern abstraction layers, you might sometimes see a field that says "sector size" reported as 512, on a modern "advanced format" disk which uses 4KB physical sectors.

Answer 3

After some digging it turns out that the appropriate way to get block size is

root@ubuntu-xenial:/proc# blockdev --getbsz /dev/sda
4096

It may of course differ from one block device to another.

In any case the above value seems to be consistent with the output of dumpe2fs