In the previous part we have realized that we have disk actually smaller, then we thought, when we were buying it. Now we will investigate what is the overhead of the ext3 file system itself, where and why the space is used.

To start we will look again to our fdisk output, but a bit from a different point of view, (with -u option).

From this output we can see that
Total disk size = 999989182464
and Total disk sectors = 1953103872

Also we can count that Disk sectors used for partition = 1953102374 – 63 + 1 = 1953102312

Interesting number! 1953103872 - 1953102312 = 1560 sectors lost. Which is 1560 * 512 = 286720 bytes. On my another 500G drive this value was about 7 Mebibytes. This is unknown for me, I suppose this is just roundup of usable space on the disk.

So Partition size is 1953102312 * 512 = 999988383744 bytes
Or if we will count in fylesystem blocks (which is by default 4k)
Partition 4k blocks = 999988383744 / 4096 = 244137789

This is exactly what we saw during the format

We know from the theory that ext3 file system consists of block groups.

This is done to optimize usage of the file system, make fragmentation less and increase speed. In the ext2 file system each block group consisted of Superblock, Group descriptor, Data Block bitmap, Inode bitmap, and Inode table.

From the format output we see that we have only 18 superblocks backups.

Each such block group is “full” and all the rest consists only of Data Block bitmaps, Inode bitmaps, and Inode table. This is possible because each superblock and group descriptor holds information for the whole file system. This feature appeared in ext3. Before this each Block group had the same number of available data blocks and inodes.

So Total number of super blocks = 1 primary + 18 backups = 19

I supposed that following "-O feature" makes this.

However if you will omit it, mke2fs will still create only 18 backups. I guess this is hardcoded somewhere.

Let's check how many Block groups do we have.

Number of Block groups = Fdisk Block count / blocks per group.

Blocks per group is fixed when file system is created. The block bitmap, which describes all the data blocks in the group, must fit into 1 block, hence the number of blocks per group is 8 * block size

So...

Number of Block groups = Fdisk Block count / ( 8 * block size ) = 244137789 / ( 8 * 4096 ) = 7450.494049072. Which means that we have 7450 full-sized block groups and one small. Size of the small group is 0.494049072 * 32768 = 16188 blocks. 0.999991296 blocks are lost (actually it isn't, we will see this later).

What is exactly corresponds to what we see from the mke2fs output (7451 block groups)

The size of 1 block bitmap = blocks per group * block size = 32768 * 4096 = 128M.

How much actually free usable space we have?

Each block group with super block ( totally 19 ) have
Data Blocks = Blocks Per group - (Super block + Group descriptors + Reserved GDT blocks + Data Block bitmap + Inode bitmap + Inodes table ) =
= 32768 - (1 + 59 + 965 + 1 + 1 + 512 ) = 31229

Each block group without super block ( 7450 - 19 = 7431 ) have
Data Blocks = Blocks Per group - (Data Block bitmap + Inode bitmap + Inodes table ) =
= 32768 - (1 + 1 + 512 ) = 32254

And the last small group have
Data Blocks = Blocks Per group - (Data Block bitmap + Inode bitmap + Inodes table ) =
= 16188 - (1 + 1 + 512 ) = 15674

So total Data blocks available = 19 * 31229 + 7431 * 32254 + 15674 = 240288499 blocks = 984,221,691,904 bytes.

What we see in df

Total fs size according to df is = 961227340 * 1024 = 984,296,796,160 bytes

df total size – total Data blocks = 984296796160 - 984221691904 = 75104256 bytes

df shows that Available space is 75104256 bytes bigger which is (/ 4096 =) 18336 blocks.
Probably df counts Reserved GDT blocks as free.
Reserved GDT blocks = 965 * 19 = 18335 blocks which is 1 block smaller then df output.

Couple of questions
1) Why the size of group descriptors is 59 blocks ?
2) Why the size of Reserved GDT block is 965 blocks ( Reserved GDT blocks: 965) ?
3) Why the size of inodes table is 512 blocks (Inode blocks per group: 512 )?
4) Where is that one free block?
5) And where is our journal ?

Answers (Updated):

2) The reserved GDT block is caused by this "-O feature"

So current Size of group descriptors + Reserved GDT blocks should equal 1024.
In our case 59 + 965 = 1024. So it is correct.

4) Where is that one free block?

I suppose that I did wrong assumption saying that size of the last small group is 0.494049072 * 32768 = 16188 blocks and that 0.999991296 blocks are lost. If it was rounded up to 16189 then it also makes sense.

5) Where is the journal stored?

The Ext3 journal is usually stored in a hidden file named .journal located in the root directory of the file system.

So this means that we can treat this journal as ordinary file (32768 * 4096 = 128M), which df will show us as already USED.

Let's turn off journal and see how much space we will have

204572K - 73364K = 128M

This proves the statement about journal. But why these 73364 blocks are Used? This is another question, on which I don't have answer yet. If I will not be too lazy, I will figure it out.

Let's summarize total ext3 file system overhead.

Total default ext3 file system overhead = number of block groups with superblocks * ( Super block + Group descriptors + Reserved GDT blocks + Data Block bitmap + Inode bitmap + Inodes table ) + number of block groups without superblocks * ( Data Block bitmap + Inode bitmap + Inodes table ).

In my case this equals 3859055 blocks or ~ 14.6 Gibibytes

In the next article I will do a little experiment and will try to reduce this overhead.

Links:
Understanding the Linux Kernel, 3rd Edition, By Daniel P. Bovet, Marco Cesati
The EXT2 File System, Presented by: S. Arun Nair, Abhinav Golas