You are not logged in.
Hello guys,
Do you think we all should use the "discard" option for the FAT32
filesystem of the ESP partition needed for UEFI firmwares ?
Ok, this is not a matter of life for the SSD, but I try to do the things
right, with respect to the art.
Here is my fstab line regarding ESP partition:
UUID=3694-4652 /boot/efi vfat rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro 0 2Is this option compatible with F32... not sure.
Regards,
Me
Last edited by PolePosition (2017-12-28 22:44:42)
Life is not linear.
-----------
Arch power !
Offline
Is this option compatible with F32... not sure.Is this option compatible with F32... not sure.
Well then, check 'man mount' and see.
See also https://wiki.archlinux.org/index.php/So … rives#TRIM
Sakura:-
Mobo: MSI MAG X570S TORPEDO MAX // Processor: AMD Ryzen 9 5950X @4.9GHz // GFX: AMD Radeon RX 5700 XT // RAM: 32GB (4x 8GB) Corsair DDR4 (@ 3000MHz) // Storage: 1x 3TB HDD, 6x 1TB SSD, 2x 120GB SSD, 1x 275GB M2 SSD
Making lemonade from lemons since 2015.
Offline
It's perfectly safe to use discard for ESP
Offline
Generally better to just fstrim once in a while than enabeling discard. Some devices deals pretty badly with discard.
Evil #archlinux@libera.chat channel op and general support dude.
. files on github, Screenshots, Random pics and the rest
Offline
R00KIE
Tm90aGluZyB0byBzZWUgaGVyZSwgbW92ZSBhbG9uZy4K
Offline
Err ... I couldn't blame the OP for being confused at this point. We have several RTFM type answers, which may be perfectly fitting, but only one direct answer which seems to advise against 'discard' in favor of fstrim. Yet if the OP reads the link he was pointed to twice, he will find that fat32 is not listed, but vfat is - that is the right line, right? And in that line, the wiki says that 'fstrim' is not supported, but 'discard' is.
Although that table also suggests it is for kernel versions 3.8 and up. A lot may have changed from 3.8 to now.
I don't have a dog in this, but I'm even confused by what the OP should take out of this thread. Perhaps a little more depth than RTFM would be warranted here.
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
I think it's a bad idea to mount the EFI system partition by default at all under Linux. Sooner or later you are going to break something by accident. Install rEFInd once, and then only mount the ESP if you absolutely have to.
Offline
Morn, it needs to be mounted for kernel updates. How would having it mounted break anything?
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
I have my EFI partition always mounted and the world is still spinning (there have been a few floods, droughts and large fires but I'm not to blame I swear).
As the wiki says, vfat (which includes FAT32) does not support fstrim, I have just checked on my EFI partition and it says 'fstrim: .: the discard operation is not supported', doing the same in my home directory and I get '.: 20.7 GiB (22257078272 bytes) trimmed'. Either you mount the partition with the discard option or there is no trim, but for an EFI partition that almost doesn't matter because it is a small partition.
R00KIE
Tm90aGluZyB0byBzZWUgaGVyZSwgbW92ZSBhbG9uZy4K
Offline
Morn, it needs to be mounted for kernel updates. How would having it mounted break anything?
Not if your kernel lives in /boot in your normal Linux filesystem. That's the beauty of rEFInd: not having to touch the ESP at all, unless you want to update rEFInd itself of course, which is probably rare. But for that update you do not even need the ESP in your fstab. Just mount it manually.
Between the EFI vars bricking of laptops thanks to systemd last year and occasional GRUB issue, it seems like a good idea to confine Linux to the later boot stages where it cannot cause as much EFI trouble. Leave EFI vars and the ESP alone if you can and you will never have boot problems.
Offline
If it works for you, great. But your logic is deeply flawed. The question was why not have the ESP mounted, and your reasoning is based on protecting the efivars. The problem is, accessing efivars and having the ESP mounted have absolutely nothing to do with one another. As for problems with GRUB, even if well founded, that has nothing to do with having the ESP mounted as mounting the partition and the boot loader that is used are entirely orthogonal issues. It's great you love rEFInd, but it seems like you are shoehorning recommendations for rEFInd into where they are completely irrelevant.
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
If it works for you, great. But your logic is deeply flawed. The question was why not have the ESP mounted, and your reasoning is based on protecting the efivars. The problem is, accessing efivars and having the ESP mounted have absolutely nothing to do with one another.
I know that EFI vars and the ESP are separate entities. But the point is that the laptop bricking was based on the same flawed thinking as this thread, namely those EFI vars were "mounted" (if you can call it that) by systemd as read-write at all times.
If a partition is mounted in Linux and the system experiences a power loss, the file system may get corrupted. If you boot a malfunctioning kernel, it may also get corrupted. So in a way this problem is even worse than the EFI vars issue. Because at least the EFI vars bricking had nothing to do with power loss or anything like that. The EFI vars issue was triggered by the user, but your EFI partition can get screwed up at any time without your doing.
As for rEFInd, yes, I think it is a fairly elegant solution for keeping the ESP as safe as possible, and therefore I am not shy about recommending it. Linux and EFI are not a happy marriage and you can spare yourself a lot of trouble if you keep them as far apart as possible.
Offline
I think your thinking is extremely flawed. An unclean shutdown is not going to corrupt the bootloader/manager unless that's what's being updated, in which case you need the ESP mounted anyway. There can be some advantage to keeping the kernel/initramfs on a better FS, but it's minimal.
Your whole "keep them as far apart as possible" is based on little/nothing. Having the ESP separate from /boot does nothing at all to keep them separate; the boot process is the same.
Last edited by Scimmia (2017-12-27 19:03:37)
Offline
As R00KIE notes, vfat does not support fstrim. Morn, I'm not sure where you got that idea, but it is effectively derailing the thread.
Offline
The initial question was also about doing things "right".
How much sense does it make to trim the ESP partition in the first place?
Sequential read performance wasn't affected much (<6%) by filling drive, which isn't surprising as the effects of a full drive mainly appear in write performance.
Writing on the ESP only happens at bootctl and kernel updates. That this esp writing once every few days/weeks, taking 12 milliseconds (less then the blink of an eye; 30% of 20Mbyte which writes optimally trimmed in 0.040 second) longer, doesn't seem so wrong.
Or are there aspects missing here?
Offline
Thanks guys, I think I'll remove the option from my fstab file.
Many thanks for all your comments.
Life is not linear.
-----------
Arch power !
Offline