Re: F32, enable fstrim.timer by default
by Chris Murphy
On Wed, Dec 18, 2019 at 5:32 AM Martin Kolman <mkolman(a)redhat.com> wrote:
> This will also trim thin LVs on thin pools (if any), right ?
>
> So not just hardware, it can even make "software" storage layouts faster
> & potentially even avoid pool exhaustion in some cases. :)
Just a reminder, the underlying unit, fstrim.service, uses 'fstrim
--fstab' so only fstab file systems are affected. The user would need
to change the unit file to use --all instead of --fstab to affect all
mounted file systems. I'll include that info in the change wiki. I
imagine the best practice is to copy the original unit file, edit it,
and use it as a drop in unit file in /etc ?
Unfinished change, still in progress...
https://fedoraproject.org/wiki/Changes/EnableFSTrimTimer
--
Chris Murphy
3 years, 5 months
Re: F32, enable fstrim.timer by default
by Chris Murphy
On Wed, Dec 18, 2019 at 11:10 AM Neal Gompa <ngompa13(a)gmail.com> wrote:
>
> On Wed, Dec 18, 2019 at 12:08 PM Chris Murphy <lists(a)colorremedies.com> wrote:
> >
> > On Wed, Dec 18, 2019 at 10:56 AM Chris Murphy <lists(a)colorremedies.com> wrote:
> > >
> > > One thing I see in the Ubuntu fstrim.service unit file that I'm not
> > > seeing in the Fedora fstrim.service unit file, is a conditional for
> > > containers (line 4). I'm not sure where to ask about that. Maybe
> > > upstream systemd?
> >
> > Found it. I'm not sure if util-linux would typically be found in a
> > container base image? Probably no point in calling fstrim in that
> > case, but also doesn't hurt.
> >
> > $ sudo dnf provides /usr/lib/systemd/system/fstrim.timer
> > util-linux-2.34-3.fc31.x86_64 : A collection of basic system utilities
> > Repo : @System
> > Matched from:
> > Filename : /usr/lib/systemd/system/fstrim.timer
> >
>
> Yeah, util-linux is pretty common in some types of containers. It
> probably makes sense to send a PR to add that conditional.
Appears to be in the upstream version already.
--
Chris Murphy
3 years, 5 months
Re: F32, enable fstrim.timer by default
by Chris Murphy
readd cloud@ list
On Wed, Dec 18, 2019 at 5:32 AM Martin Kolman <mkolman(a)redhat.com> wrote:
>
> On Wed, 2019-12-18 at 13:11 +0100, Martin Pitt wrote:
> > Hello Chris,
> >
> > Chris Murphy [2019-12-17 22:23 -0700]:
> > > 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?
> >
> > This is a function/property of hardware, so it's IMO not desktop specific at
> > all. Servers suffer just as well from hard disks becoming slower.
> This will also trim thin LVs on thin pools (if any), right ?
Correct.
> So not just hardware, it can even make "software" storage layouts faster
> & potentially even avoid pool exhaustion in some cases. :)
Maybe. I'm not sure either way if someone would actually notice
performance improvements, but it wouldn't make them worse. And yes,
potentially avoid pool exhaustion, in particular in under provisioned
cases.
I forgot to mention: with qemu/kvm/libvirt VM's, the trim would not
get passed down to the backing storage due to default settings. The
discard mode "unmap" is supported with a SCSI disk using virtio SCSI
controller; I see some curious works/doesn't work with "plain" virtio
disk. But when it works, it does pass down to underlying thinp LV and
raw files. If anyone is doing raw file backups, or otherwise paying
for storage, it could save them some coins. And when it doesn't work,
literally nothing happens: the file doesn't get holes punched out, but
there's also no corruption (I test these things with a Btrfs scrub; it
will consistently always complain if a single metadata or data
checksum mismatches).
Anyway, it's an optimization. Pretty well tested elsewhere at this
point. And offhand not aware of any liabilities, but thought I'd ask
about it before writing up a system wide change proposal.
One thing I see in the Ubuntu fstrim.service unit file that I'm not
seeing in the Fedora fstrim.service unit file, is a conditional for
containers (line 4). I'm not sure where to ask about that. Maybe
upstream systemd?
$ cat /lib/systemd/system/fstrim.service
[Unit]
Description=Discard unused blocks on filesystems from /etc/fstab
Documentation=man:fstrim(8)
ConditionVirtualization=!container
[Service]
Type=oneshot
ExecStart=/sbin/fstrim --fstab --verbose --quiet
ProtectSystem=strict
ProtectHome=yes
PrivateDevices=no
PrivateNetwork=yes
PrivateUsers=no
ProtectKernelTunables=yes
ProtectKernelModules=yes
ProtectControlGroups=yes
MemoryDenyWriteExecute=yes
SystemCallFilter=@default @file-system @basic-io @system-service
chris@chris-Standard-PC-Q35-ICH9-2009:~$
--
Chris Murphy
3 years, 5 months
F32, enable fstrim.timer by default
by Chris Murphy
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...
[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...
--
Chris Murphy
3 years, 5 months
Automatic Network Configuration in Cloud with NetworkManager
(nm-cloud-setup)
by Thomas Haller
Hello,
We (NetworkManager) are working on a tool that should help configuring
NetworkManager in cloud.
This is for example for configuring the secondary IP addresses on
AWS/EC2 ([1], [2])
[1] https://aws.amazon.com/premiumsupport/knowledge-center/ec2-centos-rhel-se...
[2] https://aws.amazon.com/premiumsupport/knowledge-center/ec2-ubuntu-seconda...
It's inspired by and serves a similar purpose as SuSE's cloud-netconfig
([3], [4]) and ec2-net-utils package on Amazon Linux ([5]).
[3] https://www.suse.com/c/multi-nic-cloud-netconfig-ec2-azure/
[4] https://github.com/SUSE-Enceladus/cloud-netconfig
[5] https://github.com/aws/ec2-net-utils
The tool can be triggered via a systemd.timer and/or a NetworkManager
dispatcher scripts. Then it fetches meta data from the Instance
Metadata Service (thereby detecting whether it runs in a cloud
environment). Finally it configures the networking using
NetworkManager.
Currently it only supports EC2 and IPv4. But if the tool shows to be
useful, it could be extended to also support other cloud providers
(Azure).
There is a merge request on review ([6], [7]). There is a bit of a
hurry to get this merged, because it should make the cut for the next
NetworkManager release. So, I will merge it soon to master, albeit
still in an experimental state.
[6] https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_reques...
[7] https://bugzilla.redhat.com/show_bug.cgi?id=1642461
The plan is that cloud images could install and enable the tool, so you
boot a (Fedora) image and networking would just work.
Is there interrest in something like this? Any comments, questions?
best,
Thomas
3 years, 6 months
