Red Hat Bugzilla – Bug 986648
RFE: optimize automatic partitioning (and devicefactory) use of SSD
Last modified: 2018-02-14 21:37:02 EST
Description of problem:
Could you add support for SSD disk detection in anaconda, and proper handling it? I mean, that anconda should properly:
- detect erase block, and add proper mkfs options during creating FS
- add relevant options to fstab (like discard, noatime or relatime)
Could you be more specific about what actually happened when you attempted to install to the SSD?
Did you get an exception?
Was the SSD detected?
Was the file system corrupt?
If the install succeeded, there should be log files in /var/log/anaconda/ on the installed system. Could you attach those as separate, uncompressed, text/plain files?
FYI, you can configure mount options and file system tuning in a kickstart file:
15.4. Kickstart Options
part or partition
How are you installing?
Disclaimer: I have never used these options.
Created attachment 777237 [details]
Created attachment 777238 [details]
Created attachment 777239 [details]
Created attachment 777240 [details]
Created attachment 777241 [details]
Q: Did you get an exception?
A: No exception.
Q: Was the SSD detected?
Q: Was the file system corrupt?
(In reply to Steve Tyler from comment #2)
> FYI, you can configure mount options and file system tuning in a kickstart
End user, ould expect, that one's ssd wold be treated as expected automatically by anaconda, without kickstart intervention. But, thanks for you input.
I expect, that if anaconda would detect SSD drive as a 'target' drive, then it will:
- detect erase block for this ssd (using /sys or using https://github.com/bradfa/flashbench)
- properly align partition/lvm/luks on this drive (using information from above)
- use correct mkfs options to enhance performance (eg. http://wiki.gentoo.org/wiki/SSD)
Those steps, are essential, because it is hard to change it after installation.
And anaconda optionally could (it is not required, because one can change it after system is boot):
- activate trime on all LUKS/LVM/FS
- change I/O scheduler (eg. noop)
model: ATA OCZ-AGILITY4 path: /dev/sda type: 1
I think this is a dupe of bug#759920
Anyways, short of doing regex on the model of the drive you can fairly accurately detect SSDs through a combination of:
It looks like Ubuntu will be integrating this into their installer: http://www.phoronix.com/scan.php?page=news_item&px=MTUxOTY
Additional problems that are likely to be of interest:
1) Does the SSD need a block of unallocated data to function appropriately?
- How can that be decided?
- How can anaconda do that automagically (because doing it manually is a PITA)
2) What happens to an SSD if the partition is marked as "encrypted". Is
encryption weakened? Is the SSD inappropriately used? Currently, the
partition is not filled with random data in the first place, and thus
most of the space allocated to the partition can be used by SSD controller
during write consolidation, but is this really a good thing?
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.