The output of a mke2fs command is as follows

root@localhost:~# mke2fs /dev/xvdf
mke2fs 1.42.9 (4-Feb-2023)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
6553600 inodes, 26214400 blocks
1310720 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=4294967296
800 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks:
    32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
    4096000, 7962624, 11239424, 20480000, 23887872
Allocating group tables: done                            
Writing inode tables: done                            
Writing superblocks and filesystem accounting information: done

What I don't understand over here is this line

32768 blocks per group, 32768 fragments per group

I understood that the sectors(generally 512B) in a hard disk are first divided into small groups. The groups of sectors is called as blocks. In every block group I have 32768 blocks.

What I don't understand here are the fragments.

What are they? What does it signify? And if its possible to alter fragments in my FS.


2 Answers 2


Linux deliberately tries to be unix compatible. We are looking at a unixism here, a concept which the ext2/ext3/ext4 filesystems never found important enough to implement.

In 1996 McKusick et al. explained the notion on p. 271 of "The Design and Implementation of the 4.4 BSD Operating System".

The section starts by observing that large blocksize can be helpful. So when reading a large file from a pair of filesystems, one with 1-KiB the other with 8-KiB blocksize, we see faster elapsed time and less overhead from larger blocksize.

But this comes at a cost, since most "filesystems contain primarily small files. A uniformly large block size will waste space." Recall that dollars spent to acquire a terrabyte of disk storage, then and now, were markedly different.

It goes on to examine a study of some then-typical filesystems, having median file size < 2 KiB and average size of 22 KiB. This suggests putting a small file, or the tail end of a bigger file, in a "fragment". We might have eight 1-KiB fragments in an 8-KiB block, storing the contents of eight separate files.

tl;dr: The motivation behind fragments is to avoid wasting most of an 8-KiB block that would just store zeros at the end of a tiny file. The changing economics of storage changed the motivations.


The man page for mke2fs in Debian stretch (e2fsprogs version 1.43.4) says

mke2fs accepts the -f option [to specify the size of fragments] but currently ignores it because the second extended file system does not support fragments yet.

and the newer ones don't have any mention of fragments, so... it's likely something that hasn't actually ever existed. I don't know what it would have been, though.

You must log in to answer this question.

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