lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:	Mon, 3 Jun 2013 13:16:49 -0400
From:	Autif Khan <>
To:	"Theodore Ts'o" <>
Cc:	Felipe Monteiro de Carvalho <>,
Subject: Re: How to differentiate ext4 from ext2/3 in code?

This was very very educational for a newbie like myself. Thanks


On Fri, May 31, 2013 at 11:28 AM, Theodore Ts'o <> wrote:
> On Fri, May 31, 2013 at 07:04:18AM +0000, Felipe Monteiro de Carvalho wrote:
>> Hello,
>> I am working on a software which has its own code to mount file systems, but
>> when working on adding ext4 support I just noticed something strange. The
>> ext2/3 reader already works quite well for ext4!
>> So does anyone know what is the best way to differentiate in a file system
>> reader between ext3 and ext4?
>> The best I came up so far would be checking the size of the superblock ... for
>> ext3 it seams to be smaller I think ... but I guess people here might have
>> better ideas.
> The right way to do this is to take a look at the file system features.  In the superblock:
>         __u32   s_feature_compat;       /* compatible feature set */
>         __u32   s_feature_incompat;     /* incompatible feature set */
>         __u32   s_feature_ro_compat;    /* readonly-compatible feature set */
> If your software doesn't understand a file system feature which is in
> the incompatible feature set, it must not try to do anything with the
> file system.
> If your software is only going to read from the file system (for
> example, in the case of a boot loader, or if the file system is going
> to be mounted read-only), then it can ignore the s_feature_ro_compat
> bitmask.  If your software is intending to modify the file system and
> there is a filesystem feature bit set that it doesn't know about, it
> MUST NOT try to modify the file system.
> It's important to check the file system feature bitmasks, since over
> time, we've added new features to ext2, ext3, and ext4.  It's more
> accurate to consider ext2, ext3, and ext4 to be different
> implementations of the same abstract file system, with the ext4 file
> system driver being the most fully featureful implementation.
> When people talk about a "ext4 file system", that's basically a
> shorthand for saying that it's an ext2/3/4 file system which has
> features enabled which the traditional ext2 and ext3 drivers in more
> recent kernels do not support.  But it's not a very precise statement.
> If someone asks me to debug "an ext4 file system", I will tell them
> that it's critically important that the send me the output of
> "dumpe2fs -h" so I can see what file system features were enabled for
> that particular file system.
> Similarly, when an enterprise distribution states that they support
> "ext4 file systems", there may be some newer ext4 file system features
> (such as bigalloc, inline_data, metadata_csum) which they do not
> support, even if the enterprise kernel supports said feature.
> Generally, in these cases the distribution will ship an
> /etc/mke2fs.conf file that only enables the file system features that
> they support when the user runs the "mke2fs -t ext4" command.
> I hope this helps,
>                                         - Ted
> --
> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
> the body of a message to
> More majordomo info at
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to
More majordomo info at

Powered by blists - more mailing lists