Suggest Warning against using Ext2 on an SSD

[Paul C]

The Preparing the Disks chapter of the amd64 Handbook provides an example of applying an ext2 filesystem on the boot partition, which makes sense due to the small size of that partition. And that is what I did when I configured Gentoo onto a new 500 GB SSD. The problem with that, however, is that Ext2 does not support the fstrim or discard utilities.

And the Gentoo SSD Wiki recommends that the boot partition be flagged with "discard" in the fstab file due to the infrequency of its use. As I understand it this compounds the problem because an error message will not be generated when the boot partition is skipped over by fstrim with this setup. I only discovered the problem when I manually tried to run fstrim -v /boot and it generated an error message.

Neither the Manual nor the Gentoo SSD Wiki mentions this problem. While it is not a critical problem, since for most users it would take many upgrades before running out of write space on a boot partition, it might still be a good idea to make a note about this in the Manual and in the SSD Wiki.


For those who have installed an Ext2 filesystem on their boot partition and want to change it, I can tell you what I did, whether or not it is the easiest approach.

First, make copies of the three kernel files that were generated by "make install" somewhere outside of /boot.

Boot up on the Minimal CD and apply a new filesystem over the Ext2 (this erases the contents of /boot). I used Ext4. Note - I first applied a regular mkfs.ext4 /dev/... then repeated with mkfs.ext4 -T small /dev/... but did not see any difference in output. Is this because boot is so small (256M)?

Mount root partition onto /mnt/gentoo and boot partition onto /mnt/gentoo/boot. Follow the manual instructions for chrooting into your configuration (don't forget cd /mnt/gentoo and cp --dereference /etc/resolv.conf /mnt/gentoo/etc/ to start, followed by all of the proc, sys, and dev mount commands).

Once in, copy the three kernel files into /boot. Then change the boot entry in /etc/fstab from ext2 to the new type. Next follow the instructions for installing your bootloader. I started from scratch, reemerging it, installing it, and running grub-mkconfig. Make sure /etc/default/grub has any changes you wanted, like the init setup for systemd.

Once done, exit, cd, umount everything, reboot. That should work. fstrim should work now.

[Ant P.]

You don't need to reformat the partition. Just change the type in fstab to ext4.

[Paul C]

Hi Ant P.
I didn't reformat but I did reload grub because it was flashing an error message right after the boot menu that it couldn't find a particular device UUID but then it would continue on and boot properly. Reloading grub removed that error message.

[Paul C]

Umm, I did invoke the mkfs.ext4 command. But I didn't reformat the partition.

[Jaglover]

What's the benefit. A fraction of a second faster kernel upgrade. How often you do that. And when you do it once a week how valuable is this one saved second per week. For sake of truth, running mkfs.ext4 command is formatting.
_________________
My Gentoo installation notes.
Please learn how to denote units correctly!

[The Doctor]

Given UEFI 99% of /boot partitions should be vfat32 anyway these days...
_________________
First things first, but not necessarily in that order.

Apologies if I take a while to respond. I'm currently working on the dematerialization circuit for my blue box.

[Paul C]

Hi Jaglover,

Why not fix it? It was an error so it was incorrectly configured. Personally I can't stand to see sloppy work if it can be helped. Every time I boot up it will bug me.

Well, but I presume that running mkfs.ext4 is not optional in this case. Nonetheless, I see your point about it being a form of formatting.

Hi Doctor,

Yeah, I know this is not a huge problem. But some of us are stuck with older boards that don't like UEFI. That's why I am upgrading to a non-M.2 SSD as well. I'll run this puppy as long as it remains practical. I am only using it to code, process images, crunch data and access the internet anyways. I don't do gaming and I am not running a server so I really don't have any incentive to be at the bleeding edge here. My philosophy is to spend a little extra to get a system that will last at least five years, ten with upgrades, doing the basics well.

[Jaglover]

Why stop on half way then, get rid of /boot partition and Grub. Makes much neater system without all those extra partitions for Grub and boot.
_________________
My Gentoo installation notes.
Please learn how to denote units correctly!

[Paul C]

Jaglover,

Lol, that kind of tinkering is above my paygrade. I am an algorithm guy first and reluctant programmer second, although ironically programming has sucked me in and become my principle focus over the past couple of years. I have been working off and on on an interactive matrix language app that I envisioned as being a quick project to give me a powerful analytical engine that I can configure at a low level but has ballooned into a series of revisions and upgrades.

My tendency to launch into new projects with rose colored glasses is already killing me. Don't egg me on with another project!

[Tony0945]

[NeddySeagoon]

Tony0945,

[Tony0945]

[Jaglover]

NeddySeagoon,

by then we will have GrubXX which comes with its own video capture drivers to read your facial expressions and bluetooth module to boot your car remotely. It will not exit after loading the kernel and will download news after the OS is loaded in case its sniffing device can smell coffee. It will take a few GB from your hard drive but its nothing since your drive is so huge.
_________________
My Gentoo installation notes.
Please learn how to denote units correctly!

[krinn]

[NeddySeagoon]

If boot should be ext4, it needs to be with

[Paul C]

Hi Krinn,

That should be fine. When I bought the SSD one of the first things I did before even installing it was to lookup the Gentoo SSD Wiki. I would think that most users are going to want to familiarize themself with any new requirements of a new device like this.


Hi NeddySeagoon, always a pleasure,

As per my initial post, I ran:

mkfs.ext4 -T small /dev/sda1 (an MBR partition scheme with /boot on sda1)

Here is the relevant 'fdisk -l' output:

Device Boot Start End Sectors Size Id Type
/dev/sda1 * 2048 526335 524288 256M 83 Linux

My three kernel files (System-map, vmlinuz, config) total about 9MB. Grub takes up about 7MB.

Here is the relevant 'df -h' output:

Filesystem Size Used Avail Use% Mounted on
/dev/sda1 240M 18M 206M 8% /boot

Not sure how to interpret that regarding filesystem overhead as there is a loss from 256M allocated to a starting size of 240M then another loss of

240M - 206M = 34M

which exceeds the 18M Used. Either way it looks ok since I am only at 8% usage. Granted, I have a simple desktop setup without Netlink, for example. I don't know how big these kernels can get. And I wonder if the '-T small' option didn't signal mkfs.ext4 to use a smaller footprint?

[NeddySeagoon]

Paul C,

News, Small and Huge? set the blocks per inode ratio.
ext4 tries to guess good settings from the size of the filesystem.
Each file requires at least one inode. When you run out of inodes, the filesystem is full, not because you have run out of space, there are no more inodes for new files.

I still use 32Mb for /boot ... I've done, that since 2002 :)

I do recall a few posts about making a full /boot because the journal size took most of the filesystem.

I use

[Paul C]

NeddySeagoon,

Wow, ok, that opens up a world of info.

So that is just one-size-fits-all indiscriminate behavior when it reserves blocks on /home? Maybe they could add a flag to tell mkfs.ext4 to not reserve blocks on a partition:

maybe something like: # mkfs.ext4 --no_reserve /dev/sda4

assuming /home is on /dev/sda4.


So I see what you are saying about mkfs.ext4 varying sizes depending on partition size. My /boot block size is 1024 while my /home block size is 4096, which is kind of surprising because I thought that was hardware dependent.

I found it odd that the output of dumpe2fs on /boot includes the following lines that do not appear in the output when it is applied to /home:

RAID stride: 4
RAID stripe width: 4

I would think that that type of info is much more relevant to /home than to /boot? I don't have RAID so this is all new to me, but I did worry about trying to calculate stride and stripe when first reading up on how to properly configure an SSD. I concluded that I didn't need to specify it unless I was setting up a RAID system. But it struck me that getting the erase block size was something akin to Sir Lancelot's quest to find The Chalice and that it would be helpful if that kind of info were more readily available.

[NeddySeagoon]

Paul C,

Read

[Jaglover]

Allegedly reserved blocks help to manage fragmentation. So setting it to zero may not be the best idea even for /home. I say allegedly because if your /home is filling up then you better do something to enlarge it, fragmentation is not the first priority.
_________________
My Gentoo installation notes.
Please learn how to denote units correctly!

[NeddySeagoon]

Jaglover,

[Paul C]

NeddySeagoon,

Hmm, I will leave /boot blocksize alone for now. As you say, operationally it probably isn't a concern. But it is not optimal either. Something to fix another time.

After reading the tune2fs manpage, I learned that the default -c option is to not do mount-count dependent checking, which was a surprise because in the past it always was performed by default after some number of boots. The superblock says max mount count = -1, so it is shut off.

In the past I was using an HDD. Should e2fsck be run on an SSD? The manpage says that typically it won't do anything but replay the journal and exit. The -c option is read only testing, unless it appears twice, which will cause nondestructive read-write testing. Write testing sounds like a bad thing for an SSD.

It seems important to know what options will be used on e2fsck if tune2fs -c is used to set a positive max mount count that can trigger e2fsck.

[NeddySeagoon]

Paul C,

fsck, if the filesystem is broken, can be a very bad thing. It looks at the filesystem metadata, them makes some assumptions before it makes the metadata self consistent.
That will keep mount happy but it says nothing about any user data on the filesystem. As a result, fsck often makes a bad situation worse.

Only use fsck if you have a filesystem image so you have an undo, or some other backup, so you don't need fsck in the first place.
In the face of an unclean shutdown, mount will replay the journal in the course of mounting the filesystem.

It follows that fsck is a tool of last resort, when there is nothing left to loose.

This is true regardless of the storage media.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

[Paul C]

NeddySeagoon,

Lol, and so we come full circle vis-a-vis your tagline. Message received!