The following proposal comes out of the discussion at this weeks Server SIG
meeting[1]
Fedora Server will have:
* / (root) will be a minimum of 2 GiB and a maximum of 15 GiB
* SWAP will continue to be calculated automatically based on available RAM on
the system
* All unused space will be assigned to a volume group and available to be
assigned to new partitions or extend existing partitions.
* Anaconda will continue to handle the appropriate EFI and /boot settings
We also discussed during the meeting whether we should have a separate /var
partition by default, but the general sense was that we might be better served
by developing a mechanism to allow partitions to be split from existing mount
points, which would be more flexible going forward.
As we did not have quorum in the meeting by the point we got to this proposal,
I'm taking it to the list for discussion and votes.
For the record, the current behavior of the partitioning scheme is for / to be
given up to 50 GiB of space and then any remaining space after that is assigned
to a separate /home partition.
[1]
https://meetbot.fedoraproject.org/fedora-meeting-1/2016-03-15/serversig.201…
Hi,
This desktop@ thread [1] about a slow device restored by enabling
fstrim.service, got me thinking about enabling fstrim.timer [2] by
default in Fedora Workstation. But I'm curious if it might be
desirable in other Fedora Editions, and making it a system-wide
change?
I've checked recent versions of openSUSE and Ubuntu, and they have it
enabled. Therefore I estimate the likelihood of running into cons
(below) is pretty remote. Most people won't notice anything.
The pros:
+ when passed down to flash drives that support trim, it provides a
hint to the drive firmware about erase blocks ready for erasure. Some
devices will have improved wear leveling and performance as a result,
but this is firmware specific.
LVM [3] and dm-crypt [4] passdown appears to be enabled by default on Fedora.
+ with LVM thin provisioning, it will cause unused LV extents to be
returned to the thin pool for use by other LVs, kind of a nifty work
around for XFS not supporting fs shrink resize.
The gotchas:
+ Few, but highly visible, reports of buggy SSDs that corrupt or lose
data soon after trim being issued. By now, most have been blacklisted
in the kernel, and/or have manufacturer firmware updates. We shouldn't
run into this problem unless someone has older hardware that hasn't
been update and for some reason also hasn't been blacklisted in the
kernel.
+ Older SSD's have only non-queued trim support, which also can result
in a brief hang while the command is processed. This is highly
variable based on the device firmware, and the workload. But using
weekly fstrim is preferred for these devices, instead of using the
discard mount option in /etc/fstab.
+ Possible exposure of fs locality pattern may be a security risk for
some workflows. [4] [5]
[1]
https://lists.fedoraproject.org/archives/list/desktop@lists.fedoraproject.o…
[2]
fstrim.timer, if enabled, runs fstrim.service weekly, specifically
Monday at midnight local time; and if the system isn't available at
that time, it runs during or very soon after the next startup. The
command:
ExecStart=/usr/sbin/fstrim --fstab --verbose --quiet
fstab means only file systems in fstab are included; verbose reports
the mount point and bytes potentially discarded and is recorded in the
systemd journal; quiet suppresses errors which is typical for file
systems and devices that don't support fstrim, e.g. the EFI System
partition, which is FAT16/32; and USB flash "stick" drives, and hard
drives.
[3]
/etc/lvm/lvm.conf, if I'm reading it correctly, file system discards
are passed down:
# This configuration option has an automatic default value.
# thin_pool_discards = "passdown"
Due to this Fedora 27 feature; trim is passed down by dm-crypt as well
for LUKS volumes. Curiously because Fedora neither sets the discard
mount option for any file system, nor enables fstrim.timer, this
feature isn't being taken advantage of.
[4]
https://fedoraproject.org/wiki/Changes/EnableTrimOnDmCrypt
[5]
Trim on LUKS/dm-crypt note from upstream, section 5.19
https://gitlab.com/cryptsetup/cryptsetup/-/wikis/FrequentlyAskedQuestions#5…
--
Chris Murphy