Critique My Partition Setup

[h4rm0ny]

Slight threadjack... is this NEEDED then in Linux? I mean you do not need a partition for the windows pagefile... is that different in the Linux world I take it?

No, is the short answer. If you have less than 2GB, I would probably create a swap partition. But I haven't actually bothered with one outside of some memory constrained VM installs in years. I have 12GB RAM and a swap partition is the last thing I want. I deliberately don't make one just in case the OS is tempted to start using it.

Of course if you use up all your RAM and you don't have one your system will rapidly seize up to the point of needing to reboot just to escape system crawling Hell. But really that just ain't going to happen if the OP has 12GB like in their sig.

 

[h4rm0ny]

The only adjustments to your setup I think matter os that I would swap the FAT32 to NTFS. I've ised NTFS happily for ages in Linux. The other more pressing concern I have is whether 11.5GB is enough for your / partition. Admittedly I code on mine and have a webserver and database + logs in there, as well as a bunch of installed libraries. But I'm mentioning it because it will be annoying to find out later on that it's not big enough.

 

[Stratus_ss]

On my system I am using a total of 6.9G on my / partition. (Home is seperate). If you are doing web or other things you really should spin off a seperate /var to avoid crashing the system if it fills up or what have you

 

[doublejack]

11GB for the root partition definitely wouldn't be enough for me. I have /home on a different drive, and my / partition is still 25-30GB in size. I also code so quite a bit of room is taken up by Eclipse and such. However, games and other apps will often install to /usr or /usr/local, so those directories can grow quickly.

Linux is not the space hog Windows is, but as cheap as storage is I'd ere on the side of making / bigger than necessary rather than run the risk of falling short on space.

Finally, if / and /home are going to be on the same physical disk (the OP's SSD) then there is really no reason to have /home defined as a separate partition. It buys you nothing. Both are of type ext4 and if the drive dies you lose it all. Why not just have one partition?


Also, to add a comment on swap - I will run a swap partition on any linux box with 4GB of memory or less. On my HTPC/Steam Box I only have 2GB of physical memory, and I see the swap used pretty regularly (I have desktop gauges setup via conky and some scripts). On my main rig (my sig is woefully out of date, I'll fix it) where I have 4GB, I very rarely see the swap used... but if I'm doing a big compile, it will kick in.

If I had 12GB of ram, though, it is extremely unlikely I would create a swap partition.


My main rig has 6 hard drives. They are configured this way:

3 80GB Intel SSD's in raid 0
Windows 7 Pro and demanding games on a single partition.

150GB WD Raptor
MBR & Grub
~500MB /boot
4GB swap
remaining drive space all to /

2 1TB Hitachi drives in raid 1
~800GB NTFS partition named "Media", shared by Win7 & Ubuntu
Remaining ~200GB partition is my /home

This configuration has served me well for about four years now. Windows is smoking fast with the SSD's in raid, and Ubuntu runs nice and snappy on the Raptor, being a lot lighter of an OS. I had one of the Hitachi drives die on me, and I didn't lose anything thanks to the mirroring. Plugged in the free replacement, rebuilt the array and I was off and running again.

 

[Stratus_ss]

Finally, if / and /home are going to be on the same physical disk (the OP's SSD) then there is really no reason to have /home defined as a separate partition. It buys you nothing. Both are of type ext4 and if the drive dies you lose it all. Why not just have one partition?

This is subjective and I completely disagree. IMHO, always put home on a separate partition. It does help safeguard things like the upgrade path. I understand what doublejack is saying, but I have regretted it every time I have not had a separate /home. In addition to the ease of upgrading or moving between distros, it will also help prevent making the system unbootable due to space constraints. This is the same reason why anything that can fill up quickly should be on a separate partion.

I will admit that my bias is not as a programmer but a professional sysadmin, so my opinion is heavily influenced by what I see on a daily basis at work. Servers which do not necessarily have someone with eyes on them (yes there is monitoring software) can go bonkers and can fill up a partition before anyone can react to it (such as a program that has just spewed huge amounts of data into the log in a very short period of time).

I suppose that since this will be a desktop machine, the chances of similar things happening are lower, but I would still strongly advise at very list a /home partition

 

[h4rm0ny]

This is subjective and I completely disagree. IMHO, always put home on a separate partition. It does help safeguard things like the upgrade path. I understand what doublejack is saying, but I have regretted it every time I have not had a separate /home. In addition to the ease of upgrading or moving between distros, it will also help prevent making the system unbootable due to space constraints. This is the same reason why anything that can fill up quickly should be on a separate partion.

Actually, I agree with that as well. /home is always at least a separate partition for the reasons given - if you need to reinstall / upgrade the OS, it makes things a doddle. Of course a separate disk, ideally mirrored, is even better.

Going back to putting /var on a separate partition as well, yes - that can be good. I actually have /srv on a separate partition. But unless the OP knows what they'll need (e.g. "I'll be keeping a bajillion log files so I'll put /var on a separate directory. I'm going to develop massive media intensive websites, so I'll put /srv on a separate"), I just kept things simple and went with a caveat on / itself.

My / is 7GB currently, just to add to everyone else's results. It really can very a lot depending on what you do, but I feel it was definitely worth raising as a topic, anyway.

 

[doublejack]

OK, so it is a matter of trading one convenience for another. Either you can have more flexible use of drive space by having one root partition, or you can have more flexibility in terms of OS changes by branching /home off into a separate partition.

I opt for the former because I very seldom make OS changes like that. If I want to tinker, I figure that's what VMs are for. Also, if I do need to wipe my root partition I have the option of copying /home somewhere else temporarily.

I can see where a production server that has a smallish set of software on it that is relatively unchanging would be better served with a small and separate root partition. That would make administration easier. Plus the whole box is likely backed up nightly, most likely, so neither root nor /home partition are at much risk of data loss making the single drive failure issue a moot point.

 

[Neuromancer]

Makes me wonder if 16GB of RAM + SSD Swap is why it feels so snappy...

From what I read yesterday with 16GB of RAM you want an 18GB swap partition.

From windows experience, once you pass 4GB of RAM you can basically shrink pagefile to 256 (omitting it completely can cause issues with some archaic software). You can also eliminate that 100MB-200MB system partition by preformatting and telling 7 NOT to format the drive. Although that may have changed with SP1.

I would THINK the same holds true for linux, I let CentOS format my drive and after expecting a 6GB swap and the rest ext4, (what the wiki said) I got a whole mess of junk. It looks exactly like our unix boxes that were built in 1993. Why does boot need a partition and not just a folder???

EDIT: never mind missed a couple of posts that explain it

 

[Neuromancer]

Excellent post up there stratus!!!

I wanted to confirm that writes are not remotely a concern these days on SSDs. It really hasn't been in the last couple of gens honestly (years). For example, the OCZ Vertex 460 (think Samsung Evo - performance/budget SSD) is good for 20GB writes /day for 3 years. Good luck doing that, or 1/4 of that in a non-enterprise environment. Rarely would a home user come close to that number, DAILY.

TRIM should always be enabled AFAIK. Is there something in Linux that makes that statement false?

20GB/day sounds like a lot if you are thinking of it in terms of copying things to the drive, if you follow the SSD "tweaks" you can really improve the life. As writing 1 bit to an SSD is actually writing 1MB because the higher density NAND uses pages.

Drives today have a lower write life expectancy than they did a few years ago, and I have had a few SSDs die on me with just months of use.

Theoretically without write caching. You can write the entire density of an SSD with just a couple hundred bits of information (it would have to be broken up to 1 bit per page so 1bit = 1MB). It is about the OS's and controllers write algorithms and caching to be able to minimize the impact of drive writes. Which they are.. but still Large file writes are less damaging then a large number of smaller files.

Off track thought, I do not have the resources anymore to test this out. But I wonder (like RAID of old) how cluster size would affect write life. Setting cluster to page size would seem like the best method to me. Reducing stress on the controller and prolonging total ssd life not just that of the NAND.


EDIT: Little rusty. Writes = erase then write 1 Block at time. There are a number of pages in a block so to write one bit to one page an entire block must be erased and then written. MLC NAND at a 16Gb density is over 512K that must be written to write a one or a zero to a drive. TLC varies from 64Gb-128Gb in density, so the erase and write program is working with a much larger amount of data. (2+MB-4+MB of writing not counting having to erase it first).

 

[h4rm0ny]

From what I read yesterday with 16GB of RAM you want an 18GB swap partition.

That doesn't actually make sense - 'the larger your RAM the more Swap space you need', it's actually the other way around. I think what you've got hold of is a tangled version of an old rule of thumb which was "how much swap space should I configure? A: about twice what your RAM is". And that came about because lacking a good reference point for people asking such a general question, twice your RAM was probably about what you'd likely want because if you were using even more swap space than that, then you'd have outpaced your RAM by too much and would probably spend all day swapping things in and out.

But that's a principle from the days when RAM was very much more limited. Maybe it's still a good rule of thumb if you have 1-2GB, but for 12GB it has clearly broken down.

 

[doublejack]

Someone correct me of I'm mistaken, but I believe the rule of thumb of the swap needing to be bigger than physical memory still exists because of suspend and hibernate modes. For deep power savings, the memory is powered down and the contents are written out to swap.

So if you want to hibernate a rig with 16GB of ram, you would need something like 18GB of swap.

Now, you can configure linux to suspend to a swap file instead of a partition, but I think for most distros that requires some tweaking.

 

[Stratus_ss]

Someone correct me of I'm mistaken, but I believe the rule of thumb of the swap needing to be bigger than physical memory still exists because of suspend and hibernate modes. For deep power savings, the memory is powered down and the contents are written out to swap.

So if you want to hibernate a rig with 16GB of ram, you would need something like 18GB of swap.

Now, you can configure linux to suspend to a swap file instead of a partition, but I think for most distros that requires some tweaking.

Yup this is correct

 

[Tyerker]

So wait, I should be looking at like a 20gb swap?

 

[Stratus_ss]

If you plan on doing suspend to disk. Otherwise normal swap comments apply

 

[h4rm0ny]

Someone correct me of I'm mistaken, but I believe the rule of thumb of the swap needing to be bigger than physical memory still exists because of suspend and hibernate modes. For deep power savings, the memory is powered down and the contents are written out to swap.

So if you want to hibernate a rig with 16GB of ram, you would need something like 18GB of swap.

Now, you can configure linux to suspend to a swap file instead of a partition, but I think for most distros that requires some tweaking.

Huh. That makes a lot of sense. I never knew about that connection.

But seriously, don't suspend to disk 16GB of RAM. It would take forever to shutdown and restart if you actually had used that 16GB.

 

[doublejack]

It depends on what kind of storage you have, really. The wake-up time is the one that matters the most. If you have a drive with fast reading, you can wake up a box with a lot of memory pretty quickly. Even 10 seconds to wake-up is quicker than usual boot times.