UEFI + SSD: What is the best strategy?

srulop · 2013-12-01 18:30:33

Hi,

I want to buy an SSD for my laptop, and perform a fresh install. So far, I've been using UEFI boot, which required a small FAT32 partition on the hard drive. But wouldn't putting a FAT partition on an SSD reduce it's performance/longevity? I mean because of the fact that FAT does not support TRIM. So is it better to use "legacy" boot with SSD?

And another question:
On HDD I used 4 different partitions: /boot (FAT) and /, /var & /home (ext4). Is there a reason to separate root var and home on an SSD? (because fragmentation is not a problem there, and I see no other reason to separate root from data, if using only a single OS.)

What do you think?

Thanks!

mcloaked · 2013-12-01 19:44:49

srulop wrote:

Hi,
I want to buy an SSD for my laptop, and perform a fresh install. So far, I've been using UEFI boot, which required a small FAT32 partition on the hard drive. But wouldn't putting a FAT partition on an SSD reduce it's performance/longevity? I mean because of the fact that FAT does not support TRIM. So is it better to use "legacy" boot with SSD?
And another question:
On HDD I used 4 different partitions: /boot (FAT) and /, /var & /home (ext4). Is there a reason to separate root var and home on an SSD? (because fragmentation is not a problem there, and I see no other reason to separate root from data, if using only a single OS.)
What do you think?
Thanks!

I have been using an ssd (well actually two - one mSATA and one SATA) on a home built system for about a year - I have a VFAT ESP for UEFI boot and the system has been operating flawlessly since the build without any problems at all. So at least from my experience there is no reason not to have the VFAT partition on an ssd to boot via UEFI.

One reason to separate /home from other system partitions is that if a user fills up the /home partition at least it does not then fail the system - and you can boot into superuser and fix things - so having /home separated from / and if you like from /var as well is actually quite a useful strategy.

Last edited by mcloaked (2013-12-02 10:42:03)

WonderWoofy · 2013-12-01 20:10:44

srulop wrote:

But wouldn't putting a FAT partition on an SSD reduce it's performance/longevity? I mean because of the fact that FAT does not support TRIM. So is it better to use "legacy" boot with SSD?

I take it you didn't actually look into this at all did you?

srulop · 2013-12-01 22:12:20

Thanks, mcloaked. That was more or less what I thought, but wanted to make sure I'm not doing someting odd here.

brain0 · 2013-12-02 10:03:57

srulop wrote:

But wouldn't putting a FAT partition on an SSD reduce its performance/longevity?

FUD? I don't get why people are so worried about their SSDs dying quickly.

srulop wrote:

I mean because of the fact that FAT does not support TRIM.

More FUD? You can use the discard mount option with FAT.

qinohe · 2013-12-02 10:52:28

If you would like to know more about your vfat filesystem, https://www.kernel.org/doc/Documentatio … s/vfat.txt

ANOKNUSA · 2013-12-02 16:05:55

brain0 wrote:

srulop wrote:
But wouldn't putting a FAT partition on an SSD reduce its performance/longevity?
FUD? I don't get why people are so worried about their SSDs dying quickly.
srulop wrote:
I mean because of the fact that FAT does not support TRIM.
More FUD? You can use the discard mount option with FAT.

Even if write cycles were still a concern (they're not), the EFI partition shouldn't need to be more than the 512Mb minimum unless the user is booting a truck-load of operating systems, so dedicating .001% (or whatever) of your disk to FAT hardly seems risky.

srulop, I recommend looking into how UEFI works on Linux a bit more, and maybe reading up on SSDs some more; the Arch wiki pages on UEFI and SSDs should contain enough info to get started. As for partitioning, your reason for using four different partitions (fragmentation) seems like it fell out of relevance quite some time ago, SSD or no. Unless you're using LVM or BTRFS, splitting your disk up in that way is liable to just waste space. You'll likely want a separate /boot for UEFI (the wiki should hint at why), and you can control the pacman cache and log rotation manually to better handle space usage in /var.

Last edited by ANOKNUSA (2013-12-02 16:06:45)

srulop · 2013-12-02 18:07:07

brain0 wrote:

More FUD? You can use the discard mount option with FAT.

Thanks! I really didn't know that!
The wiki states:

As of linux kernel version 3.7, the following filesystems support TRIM: Ext4, Btrfs, JFS, and XFS.

(https://wiki.archlinux.org/index.php/So … rives#TRIM)
Although this: https://www.kernel.org/doc/Documentatio … s/vfat.txt indeed says othervise.

Guys, I've read UEFI, SSD and many more articles in the wiki from top to bottom several times. Yeah, I know, the question was noob-formulated. That was intentionally. Just wanted to make sure everything was OK, although was 99.9% sure it was.

By the way, I don't get it why people are NOT concerned about write cycles on SSD: the numbers I hear are 19 years for TLC NAND and 60 for MLC. (Source: http://www.ubergizmo.com/2013/05/samsun … view-256gb)
Let's say I want to use my storage for 10 years (reasonable, I guess) so x2-x6 overestimation is not that much in engineering... But that, I guess, is an off-topic.

Thanks for the answers!

Last edited by srulop (2013-12-02 18:10:28)

Arch Linux

#1 2013-12-01 18:30:33

UEFI + SSD: What is the best strategy?

#2 2013-12-01 19:44:49

Re: UEFI + SSD: What is the best strategy?

#3 2013-12-01 20:10:44

Re: UEFI + SSD: What is the best strategy?

#4 2013-12-01 22:12:20

Re: UEFI + SSD: What is the best strategy?

#5 2013-12-02 10:03:57

Re: UEFI + SSD: What is the best strategy?

#6 2013-12-02 10:52:28

Re: UEFI + SSD: What is the best strategy?

#7 2013-12-02 16:05:55

Re: UEFI + SSD: What is the best strategy?

#8 2013-12-02 18:07:07

Re: UEFI + SSD: What is the best strategy?

Board footer