Bug 444527 - RFE: ext4/ext4dev support in anaconda for RHEL5
RFE: ext4/ext4dev support in anaconda for RHEL5
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: anaconda (Show other bugs)
5.3
All Linux
low Severity low
: rc
: ---
Assigned To: Radek Vykydal
Alexander Todorov
:
Depends On:
Blocks: 447797
  Show dependency treegraph
 
Reported: 2008-04-28 17:35 EDT by Eric Sandeen
Modified: 2009-01-20 16:38 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-01-20 16:38:03 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
ext4dev support for formatting non-system partitions in install (4.16 KB, patch)
2008-08-13 07:53 EDT, Radek Vykydal
no flags Details | Diff
ext4dev support - detection of partitions (1.29 KB, patch)
2008-08-13 07:58 EDT, Radek Vykydal
no flags Details | Diff
ext4dev and ext4 support - detection and formatting (nonsystem partitions) (9.37 KB, patch)
2008-08-19 10:00 EDT, Radek Vykydal
no flags Details | Diff
traceback met when upgrade doesn't find any root partitions (46.03 KB, text/plain)
2008-08-19 10:11 EDT, Radek Vykydal
no flags Details
patch for exception when no root partition is found in upgrade (556 bytes, patch)
2008-08-19 10:18 EDT, Radek Vykydal
no flags Details | Diff

  None (edit)
Description Eric Sandeen 2008-04-28 17:35:36 EDT
We're starting to get some testing of ext4 on RHEL5, and we may get it to a tech
preview status by RHEL5.3 - to support this, a few system utilities could use
updates for ext4.

Although we probably don't need install-onto-ext4dev support, the ability to
create or recognize ext4 partitions may be useful in anaconda.  Because this era
of anaconda has it's own hand-rolled fs recognition, it will likely try to mount
ext4dev filesystems it finds as ext4, and fail.  It'd be worth making sure that
if it does fail it doesn't do so in spectacular fashion.

I can try some testing of this too, but want to log bugs for any applications
which may be affected.  This one might wind up being NOTABUG or WONTFIX. 

Thanks,
-Eric
Comment 1 Eric Sandeen 2008-05-08 16:12:20 EDT
"it will likely try to mount ext4dev filesystems it finds as ext4, and fail."

Make that "as ext3, and fail."
Comment 3 Eric Sandeen 2008-07-03 14:47:29 EDT
No, I haven't actually seen anything spectacular ;)

But we should probably make sure that the mere presence of an ext4[dev] fs on
the box doesn't make anaconda choke during an upgrade, at a minimum.

-Eric
Comment 4 Chris Lumens 2008-07-11 16:06:43 EDT
Radek - there are a bunch of ext4-related commits in Rawhide that'll be useful
here.  We're not interested in ext3-to-ext4 filesystem migration, just the
ability to make new ext4 partitions and not traceback if we see existing ones. 
Shouldn't be too bad. 
Comment 5 RHEL Product and Program Management 2008-07-11 16:21:28 EDT
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.
Comment 8 Radek Vykydal 2008-07-17 07:36:25 EDT
(In reply to comment #6)

This is my view, I should ask Chris Lumens to see and comment it,
I can be pretty mistaken somewhere. From what I learned so far:

- The kernel in RHEL5 won't support ext4, but ext4 partitions can be mounted as
  ext3 if some features of ext4, e.g. extents haven't been used in the fs
  (extents are turned on by default when mounting ext4 so chances are
  they will have been used)

- To format ext4 partitions, we need e2fsprogs >= 1.40.5 (its mke2fs 
  provides options -I 256 -E test_fs)

- For detecting ext4 partitions using libblkid we need 
  e2fsprogs-lib >= 1.40.5.

So:

> Anaconda guys,
> can you provide information what will be supported and what not? From what I
> know so far:

> * installation / format partition as ext4 - unsupported
Not sure, is there any point of being able to format an ext4 partition
in Anaconda?
If so, we can format it as ext4 and then succesfully try to mount it
as ext3.
> * rescue mode / mount ext4 partition - supported
Only in a limited way, we can try to mount it as ext3.
> * installation / install on previously partitioned ext4 disk - what happens
> here ?
Depends on ability to mount the disk, but even if we were able to
mount it as ext3, does it make sense to install on ext4 fs with ext4 features off?
> * anything else ?
* Migration - not supported, but with e2fsprogs >= 1.40.6 would be possible
(setting the test_fs flag with tune2fs).
* Upgrade of system with ext4 partitions - I think not supported.
Again, we could try to mount it as ext3.

Concerning the detection of ext4 partition I suggest to backport the patch
from Fedora, which replaces our hand-rolled detection with libblkid, to RHEL5.
For ext4 detecton, e2fsprogs 1.40.5 is needed, my guess is that older versions
will detect it as ext3, so the eventual following mount can succeed or fail
depending on features of ext4 in use. If we won't have the >= 1.40.5 lib,
and want to be able to detect ext4 as ext4 exactly, we have to hand-roll
a check for ext4 instead of backporting th libblkid (provided we're able
to do it).
Comment 9 Alexander Todorov 2008-07-17 08:06:05 EDT
(In reply to comment #8)
> (In reply to comment #6)
> 
> This is my view, I should ask Chris Lumens to see and comment it,
> I can be pretty mistaken somewhere. From what I learned so far:
> 
> - The kernel in RHEL5 won't support ext4

Then it looks to me that what we need to do is make sure anaconda will not crash
if it sees ext4 system but either not use the partition at all or offer to
format it as ext3.
Comment 10 Eric Sandeen 2008-07-17 10:46:05 EDT
In reply to comment #8, yes, it is expected that the kernel in RHEL5.3 *will*
support ext4, it is planned for tech preview.  So that probably upsets many of
the conclusions drawn in that comment ...

(the kernel itself will support ext4, so I assume that the ext4 module should
also be available within anaconda?)
Comment 11 Eric Sandeen 2008-07-17 14:31:01 EDT
For testing, I have a repo of a kernel module and userspace that can be dropped
into a current RHEL5 system:

http://people.redhat.com/esandeen/ext4/ext4-repo/

take the .repo file from there, put it in /etc/yum.repos.d, and

# yum install e4fsprogs kmod-ext4dev

then you can mkfs.ext4dev a device & mount it.

e4fsprogs also contains tools which may be appropriate for rescue mode (in
particular mkfs.ext4dev, debuge4fs and dumpe4fs) if desired.

Thanks,
-Eric
Comment 13 Radek Vykydal 2008-08-13 07:53:33 EDT
Created attachment 314196 [details]
ext4dev support for formatting non-system partitions in install

The patch enables installation of non-system ext4 partitions. The part that 
prevents using ext4 for boot partition (chunk XXX) could also have been done
by porting
commit ae1b98e7dd5038a0a11ee03d46220c76727585e8 (with change of typo: s/ext/ext4dev/)
or 2cb7a37a1e027f304607744b477cfa333968b731 from Fedora, but I preferred
the least-change patch here.
Comment 14 Radek Vykydal 2008-08-13 07:58:42 EDT
Created attachment 314198 [details]
ext4dev support - detection of partitions

The patch provides detection of ext4dev partitions, which is needed
in these cases:

- Detection of existing ext4 partitions in install. Without the patch,
ext4 is detected as ext3, and if user selects to mount it without formatting,
installation ends with error message "Error mounting... Press OK to reboot
your system". (This happens in cases when found ext4 partition uses ext3
non-compatible features).
- Identification of root partitions in upgrade and rescue mode.

The detection is somewhat clumsy, done with parsing output of dumpe4fs tool
to check presence of flag test_filesystem (using what we have in packages
from comment 11). Checking based on specific features - same as in libblkid
library - could be used, but perhaps it's better to wait until libbklid of
sufficient version itself is available and port commit
d6b03ab77abcf68c9dbb9f0c674c7dbf3548b786 and related from Fedora.
Comment 16 Eric Sandeen 2008-08-13 11:33:13 EDT
re: comment #13 - what is the reason for disallowing ext4 filesystems on "system" partitions?  Although looking at the patch it looks like it only excludes /boot ?

re: comment #15 - "Just to be sure, I think that if the partition is detected as ext4, it should be mounted as ext4 in any case, no matter if ext4 spec features
have been used or not?"

a filesystem will only be detected as ext4 *if* it is using ext4 special features - that is the definition of ext4, and how libblkid detects it.

Thanks,
-Eric
Comment 17 Radek Vykydal 2008-08-14 04:42:46 EDT
(In reply to comment #16)
> re: comment #13 - what is the reason for disallowing ext4 filesystems on
> "system" partitions?  Although looking at the patch it looks like it only
> excludes /boot ?
> 
Setting of the attribute
ext4FileSystem.linuxnativefs = 0 in ext4FileSystem's __init__
ensures that "system" partitions can't be formatted to ext4.
To quote an email from Chris with outcome of meeting with QA (Jul 25):
<cite>
However, you should not be able to make any "system" partitions on ext4.
It should be for data partitions only, since this is a tech preview.
</cite>

> re: comment #15 - "Just to be sure, I think that if the partition is detected
> as ext4, it should be mounted as ext4 in any case, no matter if ext4 spec
> features
> have been used or not?"
> 
> a filesystem will only be detected as ext4 *if* it is using ext4 special
> features - that is the definition of ext4, and how libblkid detects it.

OK, sorry for confusion from my side, I should have used
"ext4" and "ext4dev" properly in my comments. What I wanted to detect
is ext4dev, which is detected in libblkid (after telling
from jbd and checking for presence of journal) only on the basis of
test_filesystem flag.
Are we going to support ext4 or ext4dev then? The kernel module
kmod-ext4dev supports only mounting of ext4dev and requires
the presence of test_filesystem flag, so I used just this flag for
detection, and that is also the reason why I set the flag when
formatting partition as ext4dev.
Comment 18 Eric Sandeen 2008-08-14 10:06:44 EDT
regarding disallowing system partitions, I really don't see much point to it.  We know it's tech preview, and we know (and customers know) there may be bugs; disallowing ext(dev) on / only limits the scope of potential testing.  Why do we want to limit this?

Regarding detection of ext4(dev) - hm, that's an interesting one.

For now, yes, the presence of the test_fs flag is enough to detect ext4dev (which is what we are actually shipping with RHEL5.3; there is no formal "ext4" yet - the "dev" should be removed upstream soon.

Do you think it is also worth detecting ext4 (not ext4dev) in case the installer comes across such a filesystem?  At least perhaps it would be good to do a test with an ext4(notdev) filesystem in place to be sure the installer doesn't think it's ext3 and run into trouble.  Such a filesystem can be created with the "mkfs.ext4" command.

As another side note, you mention setting the test flag when formatting.  If you use the mkfs binaries from e4fsprogs (specifically, mkfs.ext4dev) and have the mke4fs.conf file available in the installer environment, you should not need to set any additional flags or options.  So:

+        self.extraFormatArgs = [ "-j", "-I", "256", "-E", "test_fs" ]

is probably not needed.  It's probably also harmless, as this just duplicates the defaults.

also, in:

+        args = [ "/usr/sbin/mke4fs", devicePath, "-i", str(entry.bytesPerInode) ]

is entry.bytesPerInode from a kickstart file, or?  One other change in upstream is that we now make fewer inodes, which may be important now that the inodes are twice as large.

Thanks,
-Eric
Comment 19 Radek Vykydal 2008-08-14 12:44:19 EDT
(In reply to comment #18)
> regarding disallowing system partitions, I really don't see much point to it. 
> We know it's tech preview, and we know (and customers know) there may be bugs;
> disallowing ext(dev) on / only limits the scope of potential testing.  Why do
> we want to limit this?
> 

I am not feeling competent about this.

> Regarding detection of ext4(dev) - hm, that's an interesting one.
> 
> For now, yes, the presence of the test_fs flag is enough to detect ext4dev
> (which is what we are actually shipping with RHEL5.3; there is no formal "ext4"
> yet - the "dev" should be removed upstream soon.
> 
> Do you think it is also worth detecting ext4 (not ext4dev) in case the
> installer comes across such a filesystem?  At least perhaps it would be good to
> do a test with an ext4(notdev) filesystem in place to be sure the installer
> doesn't think it's ext3 and run into trouble.  Such a filesystem can be created
> with the "mkfs.ext4" command.

Yes, I did such tests, and I think it is worth it, at least in case of
installation:

If ext4 partition is detected as ext3 and user selects
to mount it without formatting, then installation ends with error message
"Error mounting... Press OK to reboot your system".
(Assuming ext4 partition def= partition detected as ext4
with libblkid def= partition that "has at least one feature which
ext3 doesn't understand".)
If we detected the partition as ext4, we could disallow user to mount
it already in the partitioning UI, which is much better.

As for other cases of detection - rescue mode and upgrade,
detection happens only when searching for system root partitions,
where if ext4 is detected as ext3 it gives a message
"You don't have any linux partitions ..." in rescue mode,
and an exception (I have a patch ready) in upgrade.
Other partitions are mounted according to /etc/fstab - ext4
is just ignored in rescue, upgrade even cuts it out of /etc/fstab.

Maybe an idea for rescue mode: what about choice of setting test_fs
flag and mounting as ext4dev in case of ext4 root partition found
(e.g. user migrated it and wants to rescue it), although perhaps
with upcoming transition from ext4dev to ext4 it isn't worth
adding ad-hoc code.

> 
> As another side note, you mention setting the test flag when formatting.  If
> you use the mkfs binaries from e4fsprogs (specifically, mkfs.ext4dev) and have
> the mke4fs.conf file available in the installer environment, you should not
> need to set any additional flags or options.  So:
> 
> +        self.extraFormatArgs = [ "-j", "-I", "256", "-E", "test_fs" ]
> 
> is probably not needed.  It's probably also harmless, as this just duplicates
> the defaults.
> 

You're right, thanks for making me aware. The config didn't work for
me because I called mke4fs without -T option (fs specification).
I will fix it.


Radek
Comment 20 Radek Vykydal 2008-08-15 03:26:54 EDT
(In reply to comment #19)

I'll add true ext4FileSystem class (the present one should
be named ext4devFileSystem in fact, as it represents ext4dev, not ext4).
Internally, decision of which of them is supported is based on
checking of kernel support (/proc/filesystems), which seems to fit nice,
but we can also hard-disable the support in the code easily.
Comment 21 Radek Vykydal 2008-08-15 09:32:42 EDT
(In reply to comment #19)
(replying myself again)

Seems that the detection can work like in the table below (trying to
be as close to the libblkid detection as possible).
What fs will be detected on a partition in install
depends on what fs the KERNEL SUPPORTS (probed in /proc/filesystems)
and the flags and features the PARTITION HAS:

             |                     PARTITION HAS:                   |
KERNEL       | test_fs flag    | test_fs flag    |                  |
SUPPORTS:    |                 | special features| special features |
-------------+-----------------+-----------------+------------------+
only ext4    | ext3            | ext4            | ext4             |
-------------+-----------------+-----------------+------------------+
only ext4dev | ext4dev         | ext4dev         | ext4             |

What do you think?

This detection is displayed in UI, and both ext and ext4dev partitions
can be selected to be mounted without formatting only if kernel supports
respective fs.
The same applies on availability of fs for partition (non-system ATM)
formatting (to be discussed perhaps).
 
Radek
Comment 22 Radek Vykydal 2008-08-19 10:00:19 EDT
Created attachment 314540 [details]
ext4dev and ext4 support - detection and formatting (nonsystem partitions)

- dumpe4fs from e4fsprogs is used for detection
- detection of ext4, ext4dev is enabled always
- mounting of existing partitions is enabled if kernel supports it 
- formatting of non-system partitions is enabled if ext4 argument is given
  during boot and if the fs is mountable (kernel supports it)
- default features ans flags for formatting are taken from mke4fs.conf
  (from e4fsprogs)

Details for install are in comment #21.
Details for rescue mode and upgrade follow:

RESCUE MODE:
------------

Nonroot ext4/ext4dev partition: just tries to mount it according to /etc/fstab,
in case of fail warning about not being able to mount some partitions is
displayed.

Finding system (root partition):

1) when kernel supports only ext4dev (tested):

             |                   ROOT PARTITION HAS:                |
             | test_fs flag    | test_fs flag    |                  |
'/' in fstab:|                 | special features| special features |
-------------+-----------------+-----------------+------------------|
ext4dev      | root found,                       | message (*)      |
             | mounted on /mnt/sysimage          |                  |
-------------+-----------------+-----------------+------------------+
ext4         | root found,                       | message (*)      |
             | not mounted on /mnt/sysimage      |                  |

(*)
"You don't have any Linux partitions. Press return to get a shell.
The system will reboot automatically when you exit from the shell."
[OK]

2) when kernel supports only ext4 (not tested):

             |                   ROOT PARTITION HAS:                |
             | test_fs flag    | test_fs flag    |                  |
'/' in fstab:|                 | special features| special features |
-------------+-----------------+-----------------+------------------|
ext4dev      | root found, not mounted on /mnt/sysimage             |
-------------+-----------------+-----------------+------------------+
ext4         | root found, mounted on /mnt/sysimage                 |

UPGRADE:
--------

1) when kernel supports only ext4dev (tested)

             |                   ROOT PARTITION HAS:                |
             | test_fs flag    | test_fs flag    |                  |
'/' in fstab:|                 | special features| special features |
-------------+-----------------+-----------------+------------------|
ext4dev      | upgrade ok                        | exception (***)  |
             | '/' mounted as ext4dev after boot |                  |
-------------+-----------------+-----------------+------------------+
ext4         | message (**), reboot              | exception (***)  |

(**)
"One or more of the file systems listed in the /etc/fstab
of your Linux system are inconsistent and cannot be mounted.
Please fix this problem and try to upgrade again"
[OK]

(***)
see traceback and patch in the following comments
Comment 23 Radek Vykydal 2008-08-19 10:11:49 EDT
Created attachment 314545 [details]
traceback met when upgrade doesn't find any root partitions

happens in (***) case from comment #22
Comment 24 Radek Vykydal 2008-08-19 10:18:24 EDT
Created attachment 314546 [details]
patch for exception when no root partition is found in upgrade

happens in case (***) from comment #22
Comment 25 Eric Sandeen 2008-08-19 14:53:46 EDT
I'd really rather see ext4 as an option even for the system partitions, excluding boot (since there is a technical limitation there).

If we don't allow ext4 on root, it will never get tested, and it won't be something we can push as "stable" in RHEL5.4.

Unless someone from mgmt disagrees, can we please allow ext4 on system partitions at install time, as long as "ext4" was passed on the boot cmdline?

Thanks,
-Eric
Comment 26 Ric Wheeler 2008-08-19 15:00:58 EDT
I agree with Eric's proposal - if the user has already gone the painful step of specifying ext4 on the boot cmdline, we should let them install any file system with ext4.

ext4 is not a "might have" feature, it is going to be widely deployed across the board in the near future (if not as our new default file system).

We need to pound on it as hard as we can in tech preview!
Comment 27 James Laska 2008-08-21 08:15:48 EDT
rvykydal: This is great work!  Is it possible to extend this to support formatting all partitions (except /boot/*) as ext4?
Comment 28 Radek Vykydal 2008-08-21 08:51:18 EDT
(In reply to comment #27)

From technical/devel side, it is only only a matter of setting of one
attribute in the code; rescue mode and upgrade seemed (comment #22)
to deal reasonably with ext4dev hand-migrated root partitions, so it should
work without problems if the decision is to support ext4dev system
partitions.
Comment 29 Chris Lumens 2008-08-22 15:24:53 EDT
Radek - yeah, it sounds like we should go ahead and support system partitions on ext4 just to make sure we get it the proper testing it needs.  Thanks for taking care of this.
Comment 30 Radek Vykydal 2008-09-10 08:43:48 EDT
Fixed with commits
420b93e7f6b65156ba5bac1012820f90d8b30c0d
9317706cc48aeecb261b6d2361206e8c6ee84cb5
Will be included in 11.1.2.122.
Comment 32 Alexander Todorov 2008-11-18 09:58:29 EST
I'm moving this one to verified based on the fact that it covers a broad range of use cases and all test cases that RTT has created have executed successfully against latest builds. Any particular issues still present are best to be filed in separate bug reports so we can make ET happy.
Comment 34 errata-xmlrpc 2009-01-20 16:38:03 EST
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2009-0164.html

Note You need to log in before you can comment on or make changes to this bug.