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

[John Tall]

Hello.

I am running the Fedora 21 beta on an SSD with /boot and / on XFS. I
want to add the discard mount option to both of them, so I changed
defaults to defaults,discard in /etc/fstab and rebooted. While /boot
was mounted with the discard option / was not.

This is my /etc/fstab, actual uuids redacted:

UUID=... /                       xfs     defaults,discard        0 0
UUID=... /boot                   xfs     defaults,discard        0 0
UUID=... /boot/efi               vfat    umask=0077,shortname=winnt 0 0
UUID=... swap                    swap    defaults        0 0

I tried rebuilding the initramfs with dracut -fv, but after a reboot
still only /boot is mounted with the discard option.

# grep discard /proc/mounts
/dev/sda2 /boot xfs rw,seclabel,relatime,attr2,discard,inode64,noquota 0 0

The rest of the file systems look like this:

# grep ^/ /proc/mounts
/dev/sda4 / xfs rw,seclabel,relatime,attr2,inode64,noquota 0 0
/dev/sda2 /boot xfs rw,seclabel,relatime,attr2,discard,inode64,noquota 0 0
/dev/sda1 /boot/efi vfat
rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=ascii,shortname=winnt,errors=remount-ro
0 0

How do I mount / with the correct options?

J

[Adam Williamson]

On Sun, 2014-11-23 at 11:06 +0100, John Tall wrote:
>  Hello.
>  
>  I am running the Fedora 21 beta on an SSD with /boot and / on XFS. I
>  want to add the discard mount option to both of them, so I changed
>  defaults to defaults,discard in /etc/fstab and rebooted. While /boot
>  was mounted with the discard option / was not. 
Is / an LV?
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

[John Tall]

On Sun, Nov 23, 2014 at 5:43 PM, Adam Williamson
<adamwill(a)fedoraproject.org&gt; wrote:
>  On Sun, 2014-11-23 at 11:06 +0100, John Tall wrote:
> > Hello.
> >
> > I am running the Fedora 21 beta on an SSD with /boot and / on XFS. I
> > want to add the discard mount option to both of them, so I changed
> > defaults to defaults,discard in /etc/fstab and rebooted. While /boot
> > was mounted with the discard option / was not.
>
>  Is / an LV? 
No. They are both regular GPT partitions.

J

[Chris Murphy]

On Sun, Nov 23, 2014 at 12:27 PM, John Tall <mjtallx(a)gmail.com&gt; 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.

See if this works while you're at it:
# mount -o remount,discard /

And then check mounts. It should now show discard is enabled.

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.

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.


-- 
Chris Murphy

[John Tall]

On Sun, Nov 23, 2014 at 8:59 PM, Chris Murphy <lists(a)colorremedies.com&gt; wrote:
>  On Sun, Nov 23, 2014 at 12:27 PM, John Tall <mjtallx(a)gmail.com&gt;
> 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

[Chris Murphy]

On Sun, Nov 23, 2014 at 3:06 PM, John Tall <mjtallx(a)gmail.com&gt; wrote:

> > 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. 
Ed Greshko points to the cause for this, looks like discard can't be
added with remount. So now I think I know what's going on:

Systemd mounts the root device read only at /sysroot, and only then
can it read fstab to know what the mount options are. It then remounts
rw and includes the mount options in fstab. So any options that aren't
supported by remount, won't work.

What's odd is that I'm certain discard worked for root on Btrfs, so I
wonder if this remount limitation is XFS only or if it applies to any
filesystem? In which case, how is anyone getting trim to work on the
root device?

The only answer I'm thinking of is pretty obscure: use boot parameter
rootflags=discard. The rootflags= parameter accepts mount options and
applies them to the volume defined by root=. I only know this because
Btrfs installs depend on rootflags=subvol=<rootname> to mount the
correct subvolume containing root, and subvol=<name> is just a repeat
of what's in fstab (typically).


-- 
Chris Murphy

[Michael Cronenworth]

On 11/23/2014 05:23 PM, Chris Murphy wrote:
>  What's odd is that I'm certain discard worked for root on
> Btrfs, so I
>  wonder if this remount limitation is XFS only or if it applies to any
>  filesystem? In which case, how is anyone getting trim to work on the
>  root device? 
Limitation of xfs only.

[Chris Murphy]

On Sun, Nov 23, 2014 at 5:37 PM, Michael Cronenworth <mike(a)cchtml.com&gt; wrote:
>  On 11/23/2014 05:23 PM, Chris Murphy wrote:
> >
> > What's odd is that I'm certain discard worked for root on Btrfs, so I
> > wonder if this remount limitation is XFS only or if it applies to any
> > filesystem? In which case, how is anyone getting trim to work on the
> > root device?
>
>
>  Limitation of xfs only. 
OK. rootflags=discard should still work since it's issued at the first mount.

Chris Murphy

[John Tall]

On Mon, Nov 24, 2014 at 12:23 AM, Chris Murphy <lists(a)colorremedies.com&gt; wrote:
>  On Sun, Nov 23, 2014 at 3:06 PM, John Tall <mjtallx(a)gmail.com&gt;
> wrote:
>
> >> 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.
>
>  Ed Greshko points to the cause for this, looks like discard can't be
>  added with remount. So now I think I know what's going on:
>
>  Systemd mounts the root device read only at /sysroot, and only then
>  can it read fstab to know what the mount options are. It then remounts
>  rw and includes the mount options in fstab. So any options that aren't
>  supported by remount, won't work.
>
>  What's odd is that I'm certain discard worked for root on Btrfs, so I
>  wonder if this remount limitation is XFS only or if it applies to any
>  filesystem? In which case, how is anyone getting trim to work on the
>  root device?
>
>  The only answer I'm thinking of is pretty obscure: use boot parameter
>  rootflags=discard. The rootflags= parameter accepts mount options and
>  applies them to the volume defined by root=. I only know this because
>  Btrfs installs depend on rootflags=subvol=<rootname> to mount the
>  correct subvolume containing root, and subvol=<name> is just a repeat
>  of what's in fstab (typically). 
It worked after adding rootflags=discard to /etc/default/grub and
running grub2-mkconfig.
Thanks for the help!

J

[Ed Greshko]

On 11/23/14 18:06, John Tall wrote:
>  Hello.
>
>  I am running the Fedora 21 beta on an SSD with /boot and / on XFS. I
>  want to add the discard mount option to both of them, so I changed
>  defaults to defaults,discard in /etc/fstab and rebooted. While /boot
>  was mounted with the discard option / was not.
>
>  This is my /etc/fstab, actual uuids redacted:
>
>  UUID=... /                       xfs     defaults,discard        0 0
>  UUID=... /boot                   xfs     defaults,discard        0 0
>  UUID=... /boot/efi               vfat    umask=0077,shortname=winnt 0 0
>  UUID=... swap                    swap    defaults        0 0
>
>  I tried rebuilding the initramfs with dracut -fv, but after a reboot
>  still only /boot is mounted with the discard option.
>
>  # grep discard /proc/mounts
>  /dev/sda2 /boot xfs rw,seclabel,relatime,attr2,discard,inode64,noquota 0 0
>
>  The rest of the file systems look like this:
>
>  # grep ^/ /proc/mounts
>  /dev/sda4 / xfs rw,seclabel,relatime,attr2,inode64,noquota 0 0
>  /dev/sda2 /boot xfs rw,seclabel,relatime,attr2,discard,inode64,noquota 0 0
>  /dev/sda1 /boot/efi vfat
>
> rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=ascii,shortname=winnt,errors=remount-ro
>  0 0
>
>  How do I mount / with the correct options?
>
>  J 
Maybe you're seeing this?

https://bbs.archlinux.org/viewtopic.php?id=143254

-- 
If you can't laugh at yourself, others will gladly oblige.