Mounting XFS with discard option only works for /boot but not /

[John Tall]

On Sun, Nov 23, 2014 at 8:59 PM, Chris Murphy <lists at colorremedies.com> wrote:
> On Sun, Nov 23, 2014 at 12:27 PM, John Tall <mjtallx at gmail.com> wrote:
>
>> No. They are both regular GPT partitions.
>
> What results do you get for:
> # journalctl -b -l -o short-monotonic | grep -i discard
>
> That may reveal the attempt to (re)mount sysroot with discard and why
> it failed. If nothing comes up then boot debug options need to set.

Not much, only two lines about the /boot partition.

[   27.339461] host1 systemd[1]: About to execute: /bin/mount -n
/dev/disk/by-uuid/25692e3e-42cd-1923-bcd4-d3511ac23512 /boot -t xfs -o
defaults,discard
[   27.341034] host1 systemd[507]: Executing: /bin/mount -n
/dev/disk/by-uuid/25692e3e-42cd-1923-bcd4-d3511ac23512 /boot -t xfs -o
defaults,discard

> See if this works while you're at it:
> # mount -o remount,discard /
>
> And then check mounts. It should now show discard is enabled.

Unfortunately not, it does not show discard in /proc/mounts.

> And while you're at it confirm this:
> # sgdisk -i4 /dev/sda
>
> "partition GUID code" should be 0fc63daf-8483-4772-8e79-3d69d8477de4,
> if you use one of the freedesktop discoverable partitions
> partitiontypeGUIDs then systemd ignores fstab for that partition and
> does its own automount.

The partition GUID code is as expected
0FC63DAF-8483-4772-8E79-3D69D8477DE4. Same with -i2, the /boot
partition.

> Also FWIW discard isn't a good mount option to use for most SSDs with
> non-queuable trim support. If it's one of the very newest SSDs
> supporting queuable trim then it should be fine to set. Otherwise
> you're better off with a weekly cron issuing fstrim.

OK. Good tip! I'll do some testing if I can get discard working and
keep that in mind.

J