How does RHEL determine the FS type when you run mkfs?

Latest response

In Solaris there was /etc/default/fs - I can not find any sort of configuration file or parameter which defines the default filesystem type to use (if none is specified).

On a more annoying note: my team (all ex-Solaris guys, including myself) generally run a mkfs without a -t ... and better yet, we would add 'ext4' to /etc/fstab for our newly created FS. It seems that RHEL will mount an ext2 filesystem using ext4 in the fstab.

[root@tmsapp01 ~]# file -sL /dev/mapper/ORAAPPVG-LV_U01
/dev/mapper/ORAAPPVG-LV_U01: Linux rev 1.0 ext2 filesystem data (mounted or unclean) (large files)
[root@tmsapp01 ~]# grep u01 /etc/fstab
/dev/mapper/ORAAPPVG-LV_U01 /u01 ext4 defaults 1 2

I think my issue is too wide-spread for this to be a bug.. but I have some homework now ;-)

Responses

Hi James,

Hopefully I'm not missing your intention here...

Not sure there is a default config in RHEL such as what you have seen in Solaris... but of course you could just use mkfs.ext3, mkfs.ext4, mkfs.xfs etc as whatever default makes sense...

I use one of the following, depending on the file system I wish to create: mkfs.ext4 or with rhel7 mkfs.xfs and also here
I'm no longer using ext3 but of course mkfs.ext3 is out there.

A side note, for those customers that insist on a rhel 5.current system, I can make all file systems ext4 at kickstart with the obvious exception of /boot and of course swap is different, found that out by accident when another admin tried it.

Hoping this helps...

Regards,
Remmele

Hey Remmele - it just seems as though mkfs has to try and figure out what FS to create. My feelings towards ext4 on RHEL 5 have actually been swayed recently. It almost seems like ext4 was mostly implemented on RHEL 5 but is missing some features, etc.. and ext3 is "fully baked".

I'll probably run an strace on a mkfs to see what files it opens for reference and go that route. The only filesystems that I seem to have found with an issue are ones created after the build using mkfs - the one's from kickstart appear fine (like you mentioned).

Thanks for the input!

It wasn't very far in to the strace that it executed mkfs.ext2 (I still don't see where it did a "lookup" to determine why ext2 is the default).

# strace mkfs /dev/VolGroup00/lv_test | more
execve("/sbin/mkfs", ["mkfs", "/dev/VolGroup00/lv_test"], [/* 23 vars */]) = 0
brk(0)                                  = 0x14b3c000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2b9c4381f000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2b9c43820000
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY)      = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=99331, ...}) = 0
mmap(NULL, 99331, PROT_READ, MAP_PRIVATE, 3, 0) = 0x2b9c43821000
close(3)                                = 0
open("/lib64/libc.so.6", O_RDONLY)      = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\300\332\1\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=1720888, ...}) = 0
mmap(NULL, 3506520, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x2b9c43a21000
mprotect(0x2b9c43b70000, 2097152, PROT_NONE) = 0
mmap(0x2b9c43d70000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x14f000) = 0x2b9c43d70000
mmap(0x2b9c43d75000, 16728, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x2b9c43d75000
close(3)                                = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2b9c43d7a000
arch_prctl(ARCH_SET_FS, 0x2b9c43d7a6e0) = 0
mprotect(0x2b9c43d70000, 16384, PROT_READ) = 0
mprotect(0x2b9c43a1f000, 4096, PROT_READ) = 0
munmap(0x2b9c43821000, 99331)           = 0
brk(0)                                  = 0x14b3c000
brk(0x14b5d000)                         = 0x14b5d000
open("/usr/lib/locale/locale-archive", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=56479312, ...}) = 0
mmap(NULL, 56479312, PROT_READ, MAP_PRIVATE, 3, 0) = 0x2b9c43d7b000
close(3)                                = 0
execve("/sbin/mkfs.ext2", ["mkfs.ext2", "/dev/VolGroup00/lv_test"], [/* 23 vars */]) = 0

I wish I knew why the following occurs (or is allowed?)

[root@tst80 ~]#  mount -t ext4 /dev/VolGroup00/lv_test /mnt

[root@tst80 ~]# df -h | grep test
/dev/mapper/VolGroup00-lv_test

[root@tst80 ~]# mount | grep test
/dev/mapper/VolGroup00-lv_test on /mnt type ext4 (rw)

[root@tst80 ~]# file -sL /dev/mapper/VolGroup00-lv_test
/dev/mapper/VolGroup00-lv_test: Linux rev 1.0 ext2 filesystem data (mounted or unclean) (large files)

[root@tst80 ~]# tune2fs -l /dev/mapper/VolGroup00-lv_test | grep features
Filesystem features:      resize_inode dir_index filetype sparse_super large_file

Nice find,

We just use mkfs.[filesystem type] (i.e. mkfs.ext4, mkfs.xfs on rhel 7). Did you need to only use just 'mkfs' for a reason? I don't think I know the context of your scenario... Are you automating a file system creation?

It seems odd that ext2 is the default. I suspect your victim system is a rhel 6 system?

RHEL 5 and 6, actually. We will definitely have to change our approach to creating a new FS.

This would have been evident to us years ago if having ext4 in the fstab did NOT allow a mount of ext2. The real bummer is that you can only "upgrade" to ext3. ext4 requires a new fs to be laid down and the data copied to it :-(

What a bummer...

At least there's a method to convert from ext4 to xfs when the time comes, or if it seems like a good idea. also see this link.

Down-side to XFS vice extX being that you can't shrink filesystems. Which really sucks if you discover you've sub-optimally partitioned your disks.

Tom, is what you say above true for XFS on LVM?

XFS period.

http://xfs.org/index.php/Shrinking_Support

The mkfs binary is hard-coded to a default filesystem type of ext2:

#ifndef DEFAULT_FSTYPE
# define DEFAULT_FSTYPE         "ext2"
#endif

However, if you specify a filesystem type with -t fstype then the binary takes your parameter and executes mkfs.fstype.

For example, if you run mkfs -t ext4 then the string mkfs.ext4 is built, and then execvp(mkfs.ext4 + options) is called.

The source is in disk-utils/mkfs.c from util-linux-ng. It's only a hundred lines or so. If you understand a little C option/string parsing like argv, optind, optarg, and sprintf you'll gasp it easily.

(Note: I checked the RHEL 6.5 package built from util-linux-ng-2.17.2 when looking at this)

Thanks Jamie - your explanation makes sense (and I can't believe I have yet to catch this over the past few years).

The part I do find unacceptable is that the mount command will allow you to mount and ext2 FS as ext4. Everything else seems like a trivial annoyance compared to that mount discrepancy. Had I come across this after 5.6 was released, I likely would have tried to mount a new FS using ext4, had it fail... went through this exercise ;-) and known better.

I guess I could create a shell alias for mkfs to be mkfs.ext4 ;-)

This comes from the fact that all the ext filesystems are just feature additions on top of each other.

The features an ext2 filesystem has are valid to the ext4 driver, the driver just sees things like "no journal" and "no extents" and doesn't use the journal/extent parts of the ext4 code.

Of course, it's not a very good idea, and may cause the actually-ext2 filesystem to have changes made which make it not-ext2 anymore, so you just end up with a very feature-sparse sorta-ext4 filesystem.

I'd be surprised if we support mounting ext2-as-ext4 on RHEL 5 or 6, though the ext2/3/4 drivers have been unified into the one driver in RHEL7.

If I were in your place, I'd change procedures so people have to explicitly run mkfs.fstype when creating any filesystem (ext or otherwise) to remove any ambiguity, then confirm (and record) the filesystem type with file -s afterwards.

Just one of the many minor ways Linux and Solaris differ, I can understand how it seems odd. Growing up on Linux, the concept of a /etc/default/fs to specify a default filesystem type seems odd to me :)

Which begs the question: can you set an environmental variable to act in the stead of the passed argument? Probably a question that begs a "use the source, Luke" type of response.

Even looking in the latest mkfs source there is no reading of environment variables.

I have been following this thread from the start and think it is an interesting quirk that James has stumbled upon, and good follow up discussion, cheers to those involved.

My question is, what would trigger the 'ext2' hard coding to be updated to something newer in the source? Is it likely to remain that way to avoid possible regression?

I also agree with James' comments above regarding mounting an ext2 with ext4, even if it wasn't an error that stopped mounting but a 'notice' message at mount time eg."mounting ext2 partition", this would be enough to make me check twice.

I have a habit of using mkfs.filesystem which I think is from early ext3 days, but this thread definitely made me check my SOPs to ensure the filesystem type was explicitly specified! Thanks for posting it up.

I've pretty much always worked with UNIX OSes that supported 2+ filesystems. So, was always just a habit to be explicit. Only particular annoyance with that is that the flag varies from OS to OS.

On the other hand, being in that habit means I also tend to be in the habit of specifying FSType in other tools that support it (e.g., df, mount and a few others across OSes).

I think I had the same approach in the past Tom. In particular the Solaris default (UFS?) and VxFS - and I recall what bad things happened when someone updated /etc/defaults/fs to VxFS (what a mess).

In this case - had I not been able to mount an ext2 filesystem with ext4 in the fstab, I would have realized that it wasn't ext4 (like I had assumed).

Water under the bridge, as they say ... ;-)

what would trigger the 'ext2' hard coding to be updated to something newer in the source? Is it likely to remain that way to avoid possible regression?

I'll follow this up and let you know the response.

I spoke to our upstream util-linux maintainer. Changing the default from ext2 isn't desireable, as existing things may rely on the ext2 behaviour of mkfs.

However, the standalone command mkfs (as opposed to mkfs.fstype) is considered deprecated and will be removed altogether in a future util-linux release.

The suggested way (and in future the only way) to make filesystems on Linux is to run mkfs.fstype explicitly.

Hooray for having to re-write cofniguration-automations tools. :p

Thanks for everyone's input. I realize I might have an odd way of looking at this situation ;-)

Their proposal to remove mkfs seems completely valid (as I would NEVER have a reason to run mkfs.ext2... HA!) I guess at this point I'm beyond this as I will likely not make this mistake ever again!