Ever wondered how do ext filesystems are compatible with each other in a way that most of the times they can be mounted seamlessly even though they have ondisk different structures, or in other words how does ext ensures that the ondisk changes are compatible across different releases ?
This is possible due to three important fields present in ext superblock collectively known as compatibilty bitmaps. We will discuss each of them with anexample.
Usually when a new feature is added in ext, a bit is assigned in superblock to indicate whether the filesystem has that feature or not. The decision of putting this bit in which compatibility bitmap is of utmost importance and depends on the nature of the enhancement done.
Compatible features :(s_features_compat) (EXT3_FEATURE_COMPAT_HAS_JOURNAL - Journal support is valid)
Readonly compatible features :(s_feature_ro_compat) (EXT2_FEATURE_RO_COMPAT_SPARSE_SUPER - Filesystem has sparse superblocks ie.. there are backups of superblock in block numbers multiple of 3,5 & 7). - These are the features which are only supported if the file system is mounted in read only mode.
Incompatible features :(s_feature_incompat) EXT4_FEATURE_INCOMPAT_EXTENTS These are the features which older kernel won't be able to interpret and understand and in such cases they should refuse to mount if an incompat bit is set. One such example is the extent map changes, since it changes the way block pointers are stored on disk, older kernels who know only direct/indirect block formats will not be able to read this properly and thus can't serve data when requested.
Inorder to specify a new feature, its compatibility has to be decided and then it is added to the compatibility flags appropriately. See the macro EXT3_FEATURE_RO_COMPAT_SUPP and others to get an idea.
There have been talks and suggestions about adding these compatibility flags on per inode basis rather than the filesystem to achieve maximum backwards compatibility, so that only fewer files are non-compatible.