linux filesystem structure | file types | blocks | inodes | superblock | dumpe2fs | mkfs | partition

Every file under a filesystem has a special number called an inode. The inode is where the OS

stores the properties of the file and contains the following information:

- The file type such as regular, directory, special, link, socket, pipe, or block device

- The owner and group information

- The permissions of the file (more on this in Chapter 5, Permissions, Access,

and Security)

- Date and time on which the file was created and when last changed or read

- The file size

- The inode contains some other information as well

Things that are not available in the inode are the full path and name of the file itself. This is

stored in the /proc filesystem under the PID (process ID) of the process that owns the file.

The superblock is what ties all of the inodes together on a filesystem. It contains all of the

information needed to manage the files. Being very important to the system, most Linux

filesystems have a backup copy of the superblock at regular intervals, while also being

retained in memory.

The dumpe2fs command can be used to show the contents of the superblock.

To dump the file system information about a device

# dumpe2fs /dev/sda1 
===================================
Blocks in File System

When a partition or disk is formatted, the sectors in the hardisk is first divided into small groups. This groups of sectors is called as blocks. The block size is something that can be specified when a user formats a partition using the command line parameters available.


mkfs -t ext3 -b 4096 /dev/sda1

In the above command we have specified block size while formatting /dev/sda1 partition. The size specified is in bytes. So basically one block will be of 4096 bytes. 


Block Size for Ext2 can be 1Kb, 2Kb, 4Kb, 8Kb
Block Size for Ext3 can be 1Kb, 2Kb, 4Kb, 8Kb
Block Size for Ext4 can be 1Kb to 64Kb


The block size you select will impact the following things
Maximum File Size
Maximum File System Size
Performance


And if you are willing to store smaller files on the file system, its better to go with smaller block size as it will save a lot of disk space and also from performance perspective. 

Block Groups in File System

The blocks that we discussed in the previous section are further grouped together to form block groups for ease of access during read and writes. This is primarily done to reduce the amount of time taken while reading or writing large amounts of data.

The ext file system divides the entire space of the partition to equal sized block groups(these block groups are arranged one after the other in a sequential manner). 


Lets see an output of mke2fs command, that displays few of the information that we discussed till now.

root@localhost:~# mke2fs /dev/xvdf
mke2fs 1.42.9 (4-Feb-2014)
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

If you see the above output, it gives you the below details:

Block Size (4096 bytes)
800 Block Groups
32768 Blocks per group (which is 8*4096, as mentioned earlier)


It also shows the superblock backup locations on the partition. That is the block groups where superblock backups are stored.



What is File System Superblock?


The most simplest definition of Superblock is that, its the metadata of the file system. Similar to how i-nodes stores metadata of files, Superblocks store metadata of the file system. As it stores critical information about the file system, preventing corruption of superblocks is of utmost importance.



If the superblock of a file system is corrupted, then you will face issues while mounting that file system. The system verifies and modifies superblock each time you mount the file system.



Superblocks also stores configuration of the file system. Some higher level details that is stored in superblock is mentioned below.
Blocks in the file system
No of free blocks in the file system
Inodes per block group
Blocks per block group
No of times the file system was mounted since last fsck.
Mount time
UUID of the file system
Write time
File System State (ie: was it cleanly unounted, errors detected etc)
The file system type etc(ie: whether its ext2,3 or 4).
The operating system in which the file system was formatted


The primary copy of superblock is stored in the very first block group. This is called primary superblock, because this is the superblock that is read by the system when you mount the file system. As block groups are counted from 0, we can say that the primary superblock is stored at the beginning of block group 0.

As superblock is a very critical component of the file system, a backup redundant copy is placed at each "block group".

In other words, every "block group" in the file system will have the backup superblock. This is basically done to recover the superblock if the primary one gets corrupted.



You can easily imagine that storing backup copies of superblock in every "block group", can consume a considerable amount of file system storage space. Due to this very reason, later versions implemented a feature called "sparse_super" which basically stores backup superblocks only on block groups 0, 1 and powers of 3,5,7. This option is by default enabled in latest system's, due to which you will see backup copies of superblock only on several block groups(which is evident from the mke2fs output shown in the previous section).



How to view Superblock Information of a File System?


You can view superblock information of an existing file system using dumpe2fs command as shown below.
root@localhost:~# dumpe2fs -h /dev/xvda1
dumpe2fs 1.42.9 (4-Feb-2014)
Filesystem volume name:   cloudimg-rootfs
Last mounted on:          /
Filesystem UUID:          f75f9307-27dc-4af8-87b7-f414c0fe280f
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype needs_recovery extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags:         signed_directory_hash
Default mount options:    (none)
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              6553600
Block count:              26212055
Reserved block count:     1069295
Free blocks:              20083290
Free inodes:              6470905
First block:              0
Block size:               4096
Fragment size:            4096
Reserved GDT blocks:      505
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         8192
Inode blocks per group:   512
Flex block group size:    16
Filesystem created:       Sat Sep 27 13:05:57 2014
Last mount time:          Mon Feb  2 14:43:31 2015
Last write time:          Sat Sep 27 13:06:55 2014
Mount count:              4
Maximum mount count:      20
Last checked:             Sat Sep 27 13:05:57 2014
Check interval:           15552000 (6 months)
Next check after:         Thu Mar 26 13:05:57 2015
Lifetime writes:          305 GB
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:              256
Required extra isize:     28
Desired extra isize:      28
Journal inode:            8
First orphan inode:       396056
Default directory hash:   half_md4
Directory Hash Seed:      2124542b-ea2f-4552-afaa-c5720283d2cd
Journal backup:           inode blocks
Journal features:         journal_incompat_revoke
Journal size:             128M
Journal length:           32768
Journal sequence:         0x0151d29d
Journal start:            11415

You can also view the exact locations of superblock and backups using the same dumpe2fs command as shown below.
root@localhost:~# dumpe2fs /dev/xvda1 | grep -i superblock
dumpe2fs 1.42.9 (4-Feb-2014)
  Primary superblock at 0, Group descriptors at 1-7
  Backup superblock at 32768, Group descriptors at 32769-32775
  Backup superblock at 98304, Group descriptors at 98305-98311
  Backup superblock at 163840, Group descriptors at 163841-163847
  Backup superblock at 229376, Group descriptors at 229377-229383
  Backup superblock at 294912, Group descriptors at 294913-294919
  Backup superblock at 819200, Group descriptors at 819201-819207
  Backup superblock at 884736, Group descriptors at 884737-884743
  Backup superblock at 1605632, Group descriptors at 1605633-1605639
  Backup superblock at 2654208, Group descriptors at 2654209-2654215
  Backup superblock at 4096000, Group descriptors at 4096001-4096007
  Backup superblock at 7962624, Group descriptors at 7962625-7962631
  Backup superblock at 11239424, Group descriptors at 11239425-11239431
  Backup superblock at 20480000, Group descriptors at 20480001-20480007
  Backup superblock at 23887872, Group descriptors at 23887873-23887879