View previous topic :: View next topic |
Author |
Message |
Paul C n00b
Joined: 22 Jun 2019 Posts: 15 Location: USA
|
Posted: Wed Sep 18, 2019 6:56 pm Post subject: Suggest Warning against using Ext2 on an SSD |
|
|
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. |
|
Back to top |
|
|
Ant P. Watchman
Joined: 18 Apr 2009 Posts: 6920
|
Posted: Wed Sep 18, 2019 10:34 pm Post subject: |
|
|
You don't need to reformat the partition. Just change the type in fstab to ext4. |
|
Back to top |
|
|
Paul C n00b
Joined: 22 Jun 2019 Posts: 15 Location: USA
|
Posted: Wed Sep 18, 2019 10:48 pm Post subject: |
|
|
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. |
|
Back to top |
|
|
Paul C n00b
Joined: 22 Jun 2019 Posts: 15 Location: USA
|
Posted: Wed Sep 18, 2019 10:51 pm Post subject: |
|
|
Umm, I did invoke the mkfs.ext4 command. But I didn't reformat the partition. |
|
Back to top |
|
|
Jaglover Watchman
Joined: 29 May 2005 Posts: 8291 Location: Saint Amant, Acadiana
|
Posted: Thu Sep 19, 2019 12:33 am Post subject: |
|
|
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! |
|
Back to top |
|
|
The Doctor Moderator
Joined: 27 Jul 2010 Posts: 2678
|
Posted: Thu Sep 19, 2019 12:39 am Post subject: |
|
|
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. |
|
Back to top |
|
|
Paul C n00b
Joined: 22 Jun 2019 Posts: 15 Location: USA
|
Posted: Thu Sep 19, 2019 5:19 am Post subject: |
|
|
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. |
|
Back to top |
|
|
Jaglover Watchman
Joined: 29 May 2005 Posts: 8291 Location: Saint Amant, Acadiana
|
|
Back to top |
|
|
Paul C n00b
Joined: 22 Jun 2019 Posts: 15 Location: USA
|
Posted: Thu Sep 19, 2019 1:46 pm Post subject: |
|
|
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! |
|
Back to top |
|
|
Tony0945 Watchman
Joined: 25 Jul 2006 Posts: 5127 Location: Illinois, USA
|
Posted: Thu Sep 19, 2019 1:48 pm Post subject: |
|
|
Jaglover wrote: | 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. |
That's what I did. Only I do have grub (legacy) on systems that don't support EFI. On EFI systems I have a small EFI partition that holds reFind mounted as /boot/efi. /boot is subsumed back into /
I never again have to edit a menu, except on the old systems. And grub legacy menus are simple to edit.
No reason for separate /boot with ext2 unless the system is so old that the BIOS can't read the whole disk, i.e. over ten years old.
I agree with the OP, the manual should be updated. |
|
Back to top |
|
|
NeddySeagoon Administrator
Joined: 05 Jul 2003 Posts: 54237 Location: 56N 3W
|
Posted: Thu Sep 19, 2019 7:41 pm Post subject: |
|
|
Tony0945,
Tony0945 wrote: | I never again have to edit a menu ... |
Until once more the firmware cannot read all of the HDD ...
I think that happens once HDD reach 256PB so its a few years away yet. :) _________________ Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
Back to top |
|
|
Tony0945 Watchman
Joined: 25 Jul 2006 Posts: 5127 Location: Illinois, USA
|
Posted: Thu Sep 19, 2019 10:58 pm Post subject: |
|
|
NeddySeagoon wrote: | Tony0945,
Tony0945 wrote: | I never again have to edit a menu ... |
Until once more the firmware cannot read all of the HDD ...
I think that happens once HDD reach 256PB so its a few years away yet. |
The point was that with grub you have to update the menu every time you build a kernel. reFind finds the new kernel for you. |
|
Back to top |
|
|
Jaglover Watchman
Joined: 29 May 2005 Posts: 8291 Location: Saint Amant, Acadiana
|
Posted: Thu Sep 19, 2019 11:46 pm Post subject: |
|
|
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! |
|
Back to top |
|
|
krinn Watchman
Joined: 02 May 2003 Posts: 7470
|
Posted: Fri Sep 20, 2019 4:31 pm Post subject: Re: Suggest Warning against using Ext2 on an SSD |
|
|
Paul C wrote: | Neither the Manual nor the Gentoo SSD Wiki mentions this problem. |
It's a generic install, you cannot put every corner cases in the manual, the user is already reading it, surelly even worst, discovering linux
Else manual should cover every raid or specific controller (scsi/sas)...
But i agree it might be mention where it should, in the SSD wiki |
|
Back to top |
|
|
NeddySeagoon Administrator
Joined: 05 Jul 2003 Posts: 54237 Location: 56N 3W
|
Posted: Fri Sep 20, 2019 7:00 pm Post subject: |
|
|
If boot should be ext4, it needs to be with
On small filesystems like /boot, it was (still is?) possible to create an ext4 filesystem with a journal that left no user space. At least, not enough for a kernel. _________________ Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
Back to top |
|
|
Paul C n00b
Joined: 22 Jun 2019 Posts: 15 Location: USA
|
Posted: Sat Sep 21, 2019 12:00 am Post subject: |
|
|
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? |
|
Back to top |
|
|
NeddySeagoon Administrator
Joined: 05 Jul 2003 Posts: 54237 Location: 56N 3W
|
Posted: Sat Sep 21, 2019 8:43 am Post subject: |
|
|
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 on any filesystem I can throw away, like /boot, /tmp /usr/portage (the ebuild tree).
As root, try and look for the
Code: | Reserved block count: | Those blocks are only available to root.
On /boot, it doesn't matter as only root can write there, so there is no effect on filesystem use.
On a system with only root and boot partitions, it prevents normal users bringing the system to its knees by preventing root processes getting HDD space.
Nobody, even root, can long in to fix it.
My /home partition says Code: | Reserved block count: 18661772 |
That's really wasted space as root never writes there. It will be full to users when that many blocks remain.
The default reserved to root space is 5% but that can be changed any time.
-- edit --
The concept of the partition on an SSD is no longer useful. Certainly, it does not behave as a partition on a HDD but that's possibly another topic. _________________ Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
Back to top |
|
|
Paul C n00b
Joined: 22 Jun 2019 Posts: 15 Location: USA
|
Posted: Sat Sep 21, 2019 2:07 pm Post subject: |
|
|
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. |
|
Back to top |
|
|
NeddySeagoon Administrator
Joined: 05 Jul 2003 Posts: 54237 Location: 56N 3W
|
Posted: Sat Sep 21, 2019 2:28 pm Post subject: |
|
|
Paul C,
Read you want the -m option.
is a good read too.
Not reserving blocks on /var, or the filesystem that /var is on, is a problem waiting to happen.
Keep your install media handy, you will need it to recover.
-- edit --
There are two different block sizes here. The physical block size on the storage device itself, that's 512B, 4kb and for optical media, 32kB.
Older HDD are 512B. Newer HDD and almost all SSDs are 4kB.
The physical block size is the smallest amount that can be read/written without some sleight of hand.
The filesystem block size, for extX, is 1kB, 2kB or 4KB and by default, depends on the size of filesystem. The filesystem block size is the smallest amount of data that can be allocated/read or written to the filesystem. The two need not be related but its a good idea if they are.
Your boot has a filesystem with a 1kB block size on a device with a physical block size of 4kB. Enter the sleight of hand I mentioned earlier.
To write a 1kB block on a device with a 4kB physical block size, the SSD has to do a read/modify/write. That is, the 4kB physical block is read, 1kB is modified, then 4kB is written back. Except it can't be to an SSD, the SSD has to find a clean 4k write block, since it can't do overwrites.
This is a bigger problem than no discard.
As boot is written so rarely and both the kernel and SSD will do buffering to avoid 1kB writes, its not a real problem.
Were it anywhere else, I would fix the filesystem to use 4kB blocks, the same as the underlying physical device. _________________ Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Last edited by NeddySeagoon on Sat Sep 21, 2019 2:50 pm; edited 1 time in total |
|
Back to top |
|
|
Jaglover Watchman
Joined: 29 May 2005 Posts: 8291 Location: Saint Amant, Acadiana
|
Posted: Sat Sep 21, 2019 2:34 pm Post subject: |
|
|
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! |
|
Back to top |
|
|
NeddySeagoon Administrator
Joined: 05 Jul 2003 Posts: 54237 Location: 56N 3W
|
Posted: Sat Sep 21, 2019 2:53 pm Post subject: |
|
|
Jaglover,
Code: | lvextend ...
resize2fs ... |
No reboot required. _________________ Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
Back to top |
|
|
Paul C n00b
Joined: 22 Jun 2019 Posts: 15 Location: USA
|
Posted: Sun Sep 22, 2019 6:04 am Post subject: |
|
|
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. |
|
Back to top |
|
|
NeddySeagoon Administrator
Joined: 05 Jul 2003 Posts: 54237 Location: 56N 3W
|
Posted: Sun Sep 22, 2019 8:11 am Post subject: |
|
|
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. |
|
Back to top |
|
|
Paul C n00b
Joined: 22 Jun 2019 Posts: 15 Location: USA
|
Posted: Sun Sep 22, 2019 6:22 pm Post subject: |
|
|
NeddySeagoon,
Lol, and so we come full circle vis-a-vis your tagline. Message received! |
|
Back to top |
|
|
|