15

I'm looking for the commands that will tell me the allocation quantum on drives formatted with ext4 vs btrfs.

Background: I am using a backup system that allows users to restore individual files. This system just uses rsync and has no server-side software, backups are not compressed. The result is that I have some 3.6TB of files, most of them small.

It appears that for my data set storage is much less efficient on a btrfs volume under LVM than it is on a plain old ext4 volume, and I suspect this has to do with the minimum file size, and thus the block size, but I have been unable to figure out how to get those sizes for comparison purposes. The btrfs wiki says that it uses the "page size" but there's nothing I've found on obtaining that number.

Improve this question
1
  • Am I the only one that finds it strange that btrfs is under lvm? I’m more used to zfs, but I’m pretty sure btrfs, like zfs, also optimizes if it’s configured full stack (both volume and fs). Anyway, I seem to remember btrfs can provide better volume infrastructure than lvm.
    – Dani_l
    Commented Jun 30, 2022 at 4:41

3 Answers 3

Reset to default
17

You could use stat -f to get an answer of any filesystem, eg.:

% stat -f /home
  File: "/home"
    ID: 5013a37be3cd6a47 Namelen: 255     Type: ext2/ext3
Block size: 4096       Fundamental block size: 4096
Blocks: Total: 113391734  Free: 472450     Available: 468304
Inodes: Total: 28868608   Free: 27969906
Improve this answer
1
  • 2
    Yup, this one does not require root privilege
    – xuancong84
    Commented Dec 12, 2021 at 5:47
15

You'll want to look at the data block allocation size, which is the minimum block that any file can allocate. Large files consist of multiple blocks. And there's always some "waste" at the end of large files (or all small files) where the final block isn't filled entirely, and therefore unused.

As far as I know, every popular Linux filesystem uses 4K blocks by default because that's the default pagesize of modern CPUs, which means that there's an easy mapping between memory-mapped files and disk blocks. I know for a fact that BTRFS and Ext4 default to the page size (which is 4K on most systems).

On ext4, just use tune2fs to check your block size, as follows (change /dev/sda1 to your own device path):

[root@centos8 ~]# tune2fs -l /dev/sda1 |grep "^Block size:"
Block size:               4096
[root@centos8 ~]#

On btrfs, use the following command to check your block size (change /dev/mapper/cr_root to your own device path, this example simply uses a typical encrypted BTRFS-on-LUKS path):

sudo btrfs inspect-internal dump-super -f /dev/mapper/cr_root | grep "^sectorsize"
Improve this answer
4
  • 3
    Indeed that works for btrfs. Thanks. The relevant parts of the output are nodesize 16384 leafsize 16384
    – instance
    Commented Apr 11, 2020 at 21:01
  • 2
    🧐 ( what an obscure command to find such a basic structural FS information.. wondered about it because of snia.org/sites/default/files/SDC/2017/presentations/… )
    – eMPee584
    Commented Oct 9, 2020 at 10:00
  • 2
    @instance That's wrong. Open man mkfs.btrfs. The statistic he wants is sectorsize which is "the minimum data block allocation unit" which is how large the chunks are in file allocation. It defaults to 4K on most systems because it defaults to the page size, which is 4K on most systems. As for nodesize/leafsize, the manual explains that those are aliases for each other (always identical) and are simply the number of bytes used for each metadata block in BTRFS.
    – Mitch McMabers
    Commented Apr 19, 2021 at 17:26
  • 1
    @mitch-mcmabers Confirmed. Thanks.
    – instance
    Commented Apr 20, 2021 at 20:33
1

If you so desire to dig through a ton of unrelated information, there's btrfs-show-super -f /dev/md1. Otherwise, the answer about stat -f … is the easiest and universal one.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .