How to differentiate ext4 from ext2/3 in code?

How to differentiate ext4 from ext2/3 in code?

[Felipe Monteiro de Carvalho]

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!

Also: EXT2_SUPER_MAGIC == EXT3_SUPER_MAGIC == EXT4_SUPER_MAGIC

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.

thanks,

Felipe Monteiro de Carvalho

Re: How to differentiate ext4 from ext2/3 in code?

[Theodore Ts'o]

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!
> 
> Also: EXT2_SUPER_MAGIC == EXT3_SUPER_MAGIC == EXT4_SUPER_MAGIC
> 
> 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

Re: How to differentiate ext4 from ext2/3 in code?

[Autif Khan]

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

Autif

On Fri, May 31, 2013 at 11:28 AM, Theodore Ts'o <tytso@mit.edu> 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!
>>
>> Also: EXT2_SUPER_MAGIC == EXT3_SUPER_MAGIC == EXT4_SUPER_MAGIC
>>
>> 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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: How to differentiate ext4 from ext2/3 in code?

[Theodore Ts'o]

On Wed, Jun 12, 2013 at 07:00:57AM +0200, Felipe Monteiro de Carvalho wrote:
> Hello,
> 
> Thanks a lot, it was a really good answer =) Just to complement I see that
> some software out there uses EXT4_FEATURE_INCOMPAT_EXTENTS in the incompat
> list. It seams that this flag is usually (always?) set in ext4 but never
> (?) present in ext3
> 
> example:
> http://lists.alioth.debian.org/pipermail/parted-devel/2009-January/002488.html

It is true that the extents feature is supported by the ext4 file
system driver, and there exists no versions of the file system drivers
in the Linux kernel which supports the extents feature.

You can certainly construct file systems which have, say, the flex_bg
feature enabled has the same characteristics as the extents feature in
terms of support coverage by ext3 and ext4 implementations in the
Linux kernel, however.

It looks from the patch you've cited that parted is using some
hueristics for the purposes of displaying "ext2" vs "ext3" vs "ext4"
to the user.  That's fine from the perspective of simplifying the user
interface, but it can end up confusing the user for some unusual file
system configurations.

Regards,

					- Ted