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
"it will likely try to mount ext4dev filesystems it finds as ext4, and fail." Make that "as ext3, and fail."
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
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.
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.
(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).
(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.
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?)
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
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.
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.
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
(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.
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
(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
(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.
(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
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
Created attachment 314545 [details] traceback met when upgrade doesn't find any root partitions happens in (***) case from comment #22
Created attachment 314546 [details] patch for exception when no root partition is found in upgrade happens in case (***) from comment #22
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
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!
rvykydal: This is great work! Is it possible to extend this to support formatting all partitions (except /boot/*) as ext4?
(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.
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.
Fixed with commits 420b93e7f6b65156ba5bac1012820f90d8b30c0d 9317706cc48aeecb261b6d2361206e8c6ee84cb5 Will be included in 11.1.2.122.
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.
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