RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1285684 - [RFE] Add --fsoptions (or --mkfsoptions) for autopart directive
Summary: [RFE] Add --fsoptions (or --mkfsoptions) for autopart directive
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: anaconda
Version: 7.2
Hardware: Unspecified
OS: Unspecified
high
unspecified
Target Milestone: rc
: 7.2
Assignee: David Lehman
QA Contact: Release Test Team
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-11-26 09:16 UTC by Fabian Deutsch
Modified: 2016-08-31 14:18 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-08-31 14:18:26 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description Fabian Deutsch 2015-11-26 09:16:12 UTC 
Description of problem:
Currently a range of commands (part, raid, btrfs, …) support the --fsoptions argument to set additional fs options (liek discard) it would be nice if autopart was also supporting this.

Version-Release number of selected component (if applicable):
RHEL 7

How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:
Comment 1 Fabian Deutsch 2015-11-26 09:17:10 UTC 
The use-case is to pass the 'discard' option when the thinp layout type is used:

i.e.:

autopart --type=thinp --fstype=ext4 --fsoptions=discard
Comment 3 David Lehman 2015-12-02 14:30:50 UTC 
Isn't discard the default behavior of mke2fs? From mke2fs(8):

discard
  Attempt to discard blocks at mkfs time (discarding blocks initially is useful
  on solid state devices and sparse / thin-provisioned storage). When the device
  advertises that discard also zeroes data (any subsequent read after the discard
  and before write returns zero), then mark all not-yet-zeroed inode tables as
  zeroed. This significantly speeds up filesystem initialization. This is set as
  default.
Comment 4 Fabian Deutsch 2015-12-02 16:14:11 UTC 
Oh, I did not know about that option for mke2fs.

I was referring to either mke2fs(8) -O discard or mount(8) -o discard.
Comment 5 David Lehman 2016-02-24 16:40:24 UTC 
The difficulty here is that you are specify mount options to a command that creates multiple filesystems. The obvious behavior would be to set/use this option for all of the filesystems created by autopart. Is this what you would expect? eg: /boot and / (and /home if enough space is available) would all get the option.

Also, how would it impact RHEV 4 if this bug was deferred to 7.4?
Comment 6 Fabian Deutsch 2016-02-24 17:08:30 UTC 
Actually a valid point that it would affect multiple filesystems - and this would actually not be to nice.

In the mean time we actually improved our tool to support multiple (ext4+xfs) filesystems, which means that this RFE is not a direct blocker anymore.
Comment 7 David Lehman 2016-08-31 14:18:26 UTC 
I think this proposal has fatal flaws as described in comment 5, and am closing it on that basis. The anaconda team is not against something along these lines in principle, but this particular proposal will not work.
Note You need to log in before you can comment on or make changes to this bug.