I saw people showing their own partitioning schemes for the OP's reference. The OP is certainly smart enough to try the structure by scaling down the sizes.

BTW, Where does your 116 GB come from? If you copy/past the OP's word then it should be different. You see, we both make errors on numbers.

As to the "correct" size of swap for hibernate, ArchWiki has this to say:
The rest is @GazL.
Why tmp in RAM and no swap? Are you that worried about the data security?

I was mulling over this exact setup for my laptop, but then I decided it's too much trouble for very little benefit. If my laptop is stolen, it will almost certainly be wiped and fenced. And even if stolen for data, the cost of replacing the hardware will still be my chief inconvenience. So I went with this crazy setup (16 GiB RAM):
If I had your 16GB root, I'd be out of space already because I've installed some heavyweights like texlive and built a few kernels in /usr/src. The other thing I cannot bear is small /tmp, where I stash all media downloads, and where SlackBuilds (typically) build. It sucks I cannot secure the data properly without it being a major PITA. Self-encrypting drives are all close-sourced (can there be greater irony?), and setting up dm-crypt for root and swap, and still being able to securely hibernate is very much like pulling teeth.

Post #7, the one directly above yours. Nonetheless it would be nice if you post why you decided to go for that scheme instead of just posting your scheme.

It's very hard to answer this question without making generalisations. You really need to consider what your high water mark for usage of /tmp is and whether you can afford to spare that amount of ram. I tend to use /var/tmp a lot, so my /tmp usage is usually quite light.

On a 1GB ram machine I might try and get away with a smallish tmpfs limited to a max of 128 or at a stretch 256MB, but it's all very situational. tmpfs only uses as much ram as needed by the files in it at the time, the size you specify is just a maximum. IMO once you've got 2GB or more ram /tmp on tmpfs is a no-brainer.

Also, unlike ramfs, tmpfs is backed by swap space, so it can cope with a degree of over-commitment, but performance will suffer, which kind of defeats the purpose of having it in ram in the first place.

Is there any potential hazard to mount tmpfs on "/var/tmp"?

/var/tmp is not intended to be cleaned at reboot, so making it tmpfs is probably not a good idea.
https://en.wikipedia.org/wiki/Filesy...archy_Standard

2 members found this post helpful.

Taking a few steps back, is there any reason why the partition scheme I posted in post #3 would not work (based on TobySGD's suggestion)? I don't need an overly complicated system. Would this lead to any stability issues or would my system be slower because I don't compartmentalize it more?

Swap: 6 GB (to allow possibility for hibernate)
Root: 30 GB
Home: 80 GB

Thank you for your help.

Ok. Then it's impossible for me to get the number right anyway, because the OP does not get it consistent him/herself.

I suggested this scheme

/: 50 GB
swap: 25 GB
/usr/src: 100 GB
/home: the rest

because here / is large enough to hold a reasonable system, and swap can be used when the tmpfs contents on "/tmp" and "/var/tmp" grow too large. The big "/usr/src" is more specific to my own usage. The OP can easily omit the "/usr/src" here and get "/" and "swap" comfortably fit into a smaller disk.

---------- Post added 11-03-12 at 01:25 AM ----------

Thank you for the link. Very helpful.

No swap simply because I've never needed it on my workstation. My current memory footprint sans buffers and cache is only 246MB out of 4GB and I never hibernate.
I run an lvm based setup though, so if I do ever hit a OOM situation its pretty easy to add an lvswap. Obviously, I wouldn't risk this on a server.
The same goes for my 16GB root (though currently it's only 40% used). If I were to add something huge like texlive, I'd probably create a lvtexlive and mount it on /opt/texlive or something similar.


Just goes to show, with partitioning schemes there are no right answers. What suits one person would be completely unworkable for someone else.

That looks like a reasonable starting point if you're happy with those figures.

Just a hint, what most people consider a "normal desktop environment". If you advocate "do as the others do", you have to make sure, that these others are real.

BTW: The whole point of partitioning is to make a system more robust against crashes, file system corruption and of course free space exhaustion. Having a light root filesystem which can be mounted under worst circumstances to execute fsck/rm/whatever is better than having to fall back on rescue media, because something in /var has gone wrong.

@GAZL..what line would you add to /etc/fstab ..i've never tried this before and would like to try.

If you want to restrict it's size (it is 50% of ram by default) add something like ",size=256" after 'defaults'

man mount and scroll down to the tmpfs section for a list of all the options.

Thanks Gazl, what benefit would you say this does? ..just curious to try it.

Main benefit is it'll remove some unnecessary disk writes which may give you a small performance gain depending on your workload, but as reads will be satisfied from the vfs cache anyway, you're probably not going to notice a massive difference.