Announcement

**oshunluvr** · Jun 27, 2014, 08:52 AM

First of all, congrats on setting up auto-backup. Too often people come here weeping because they waited to backup just a minute too long. I assume you're familiar enough with rdiff-backup to avoid completing filling your backup partition unnecessarily.

I can't speak to "security" of your system re. drive partitioning as I'm not fully sure of what you mean. To me, security is preventing someone from stealing your data or damaging your file system. That s not usually a function of partitioning. If you meant "safety" as in not losing your data to a failure or leaving your system unbootable, that is a different matter.

The reason you haven't found much on the 'net is the reasons to partition this way or that are widely variable and subject to ones specific needs and tolerance for workload. I will offer my opinions, but they will be just that: my opinions. Without knowing what you use your 'puter for and your security concerns, it's hard to give specific advice.

First to performance: You have an SSD. SSDs are fast. You're barely using yours. There's no reason, with modern SSDs, to avoid using them with the possible exception of over-filling them and this includes swap. Files systems in general and SSDs particularly need some free space to work well. Keeping all your partitions below 90% full is a good idea, but use 90%. To me, having to swap out of memory is the slowest operation your OS does. I would put my swap on the SSD. You will read webpages and blogs to not do this because you can wear it out sooner, but do the math and the research (I have) and you'll see your SSD will likely outlast it's usefulness anyway. Besides, you're doing backups so you won't lose data. Why did you buy the SSD in the first place? Just to fill some space in your case? I think not. To that point, I would also have /home and /var on the SSD too. If you need more room for /home than the SSD provides, I would symlink (or bind mount) your personal data files onto the hard drive (Documents, Music, Pictures, etc.) and keep your /home and all it's settings and such on the SSD.

Also, I consider the best insurance to preventing your computer from becoming unusable is to have a second install on board. I would recommend having at least one (two is better) secondary install on one of the hard drives just in case and update breaks your main install or your SSD dies. This is also how I upgrade: Two partitions both running 14.04. When it's time to move to 14.10, boot to your backup and run the upgrade. Leave the other 14.04 alone. Once the new install is working and set up to your satisfaction, make it the default and leave the other alone, keeping it as backup. Next upgrade: Make a new install to the old 14.04 partition, making it your new default, and so on. leapfrogging through upgrades. Since you're using a single SSD, keep both of these on the SSD and have a third on sdb. The other advantage to this is if your decide to try another distro, you can install it to the sdb spare partition to test it on bare metal.

Since you're using ext4 (I don't) you should review your mounting options to be sure you're getting the best bang for your buck on the SSD's file systems. Don't run trim as a mounting option, too slow and too much drive access and not needed. Run trim as a cron job (I do it monthly)

Another performance booster - but some work to get set up - is you can use your two hard drives in a software RAID0 and put your personal data files there. You could move the backups to sdb, create a partition on sdb the same size as sdc1, using mdadm to make a RAID0 device and use that. Literately, twice as fast as a single drive alone. The hard part to setting it up will be all the data you have to move to make the space for the new partition. The RAID itself is very easy. I used to have 4 RAID devices for my system and data until SSDs got affordable.

So to sum up, my advice:

Move swap, /var, and /home to the SSD (32GB is way big for your entire install, no need to enlarge).
Make another install partition on the SSD for leapfrogging upgrades.
Move /backup to the 500GB drive.
Make another 32GB partition on sdb for backup or distro playground.
Make a 300GB (150GBx2) RAID device on sdb and sdc and use it for data.
Research and fine tune your fstab options (I use relatime rather than noatime on my SSDs for example)

My version would leave you with:

sda:
1 efi
2 swap (2-8GB ?)
3 / (32GB)
4 (leapfrog partition, 32GB)
5 /home (60GB-ish)

sdb:
1 RAID part#1 (150GB)
2 (backup install partition, 32GB)
3 /backup (320GBish)

sdc:
1 RAID part#2 (150GB)

My final comment would be to consider btrfs file system instead of ext4. Read up on it. It's great for smaller devices the 128GB SSDs because you can segregate your data using subvolumes (the are addressed like like separate partitions, but they aren't) but all the free space is available to all subvolumes. So each install and your /home will share all the free space.

**mr_raider** · Jun 27, 2014, 09:35 AM

Similar discussion:https://www.kubuntuforums.net/showth...ghlight=btrfsI ended up doing one big btrfs partition for / and home (with subvolumes), and one big ext4 partition on the HDD where II keep my downloads, torrents and live TV recordings.

**bobbicat** · Jun 27, 2014, 02:22 PM

Thank you, oshunluvr and mr_raider, you have given me much to think about
I've never set up a raid array or tried btrfs, but I am intrigued
I take your point about ssd's and their potential life, in fact I'll go so far as to say that I will take your suggestions and apply them to my system, although setting up a btrfs system will have to come later, after I've got to grips with raid and the other changes
I really appreciate your comments and I'm sure they will be extremely useful
For now, I won't mark this thread 'solved', I'll follow your advice and return with feedback on my experiences
Before I run off to start working on my PC, I have three more questions:
- do you update the 'leapfrog' install as frequently as your regular install?
- I have 16Gb RAM so maybe I should have a 16Gb swapfile?
- is relatime a relevant option in fstab for /temp tmpfs?

**oshunluvr** · Jun 27, 2014, 03:29 PM

Originally posted by bobbicat View Post

...I have three more questions:
- do you update the 'leapfrog' install as frequently as your regular install?

Not usually. I boot to it once a month or so, but since I'm not using it for daily production work, it's not vastly critical that it be updated that often. I started doing it as a backup, then I figured once I got my personal settings and taste all set up, why not save it? Then along came a new version, so I figured keep the old one around just in case. If you do this the way I describe and you upgrade at every release, you're upgrading your install every six months. If you retain the old version, it's not getting updated all that often anyway. Once a month or even less seems OK to me for service updates. I do a backup install (copy of current install) and keep a "leapfrog" (last version). Probably overkill, but I can always boot my system.

I call it leapfrog because the old install jumps two version. 12.10 becomes 13.10, etc.

- I have 16Gb RAM so maybe I should have a 16Gb swapfile?

Not unless you're using suspend/hibernate. If this is a desktop machine and you don't hibernate, I think you likely don't need a swap at all. I also have 16GB and I do have a swap (8GB), but it's really for tmpfs. If you mount tmpfs in RAM (like you are) and the available RAM space is less than half the total RAM, tmpfs will use swap if it needs more space rather than more RAM. I would consider 8GB the maximum you would need and 4GB would be just fine.

- is relatime a relevant option in fstab for /temp tmpfs?

IMO, No. Since /tmp will be erased at every reboot, time stamping is mostly useless. I would use default or noatime, nodirtime if anything. I also use mode=1777 to set the directory stickybit in /tmp (prevents others from deleting your tmp stuff). The default size of /tmp in tmpfs is half of RAM +SWAP. You can reduce that if you wish with size=6GB or whatever you want.

MDADM RAID0 setup is easy. Create the partitions, then:
Make the array:
sudo mdadm --create --verbose /dev/md0 --level=0 --raid-devices=2 /dev/sdb3 /dev/sdc1
Make it start at boot:
sudo mdadm --detail --scan >> /etc/mdadm/mdadm.conf
Then create a filesystem on it (aka format) and mount it like any other drive.

Obviously, use the partition names that you created on your system, sdb3 and sdc1 are just examples. You can names other than md0 for your RAID but I think you can cause issues if you try and use a reserved name like sdd1, so avoid those.

BTRFS RAID is even easier. Assuming the same two partitions are to be used:
sudo mkfs.btrfs -d raid0 /dev/sdb3 /dev/sdc1
Mount and done. No made up device names, no additional formatting.

**SteveRiley** · Jun 28, 2014, 06:08 PM

Originally posted by bobbicat View Post

I decided to follow the convention for ssd's and create separate areas for /home, /var and /tmp

The problem with having lots of separate partitions for various parts of the FSH (file system hierarchy) is that you may guess wrong about how big each one should be. If/when it comes time to resize them, that's just unnecessary and potentially dangerous work. I'd recommend keeping /var and /tmp on the same partition as /. The operating system frequently writes to and reads from them; why not maximize performance by placing them on your fastest storage device? Like Oshun said, the melodrama over SSD lifetime is not worth worrying about.

Originally posted by oshunluvr View Post

I would use default or noatime, nodirtime if anything.

noatime will improve performance on all partitions -- use it everywhere. It's unnecessary to specify nodirtime, as noatime includes this.

FWIW, here's my layout. Clean and simple.

Code:

steve@t520:~$ [B]lsblk[/B]
NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda      8:0    0 238.5G  0 disk 
├─sda1   8:1    0   512M  0 part /boot/efi
├─sda2   8:2    0   229G  0 part 
└─sda3   8:3    0     9G  0 part [SWAP]
sdb      8:16   0 931.5G  0 disk 
└─sdb1   8:17   0 931.5G  0 part /media/steve/Data

steve@t520:~$ [B]cat /etc/fstab[/B]
# <file system> <mount point>   <type>  <options>                               <dump>  <pass>
/dev/sda2       /               btrfs   noatime,compress=lzo,subvol=@           0       1
/dev/sda1       /boot/efi       vfat    noatime                                 0       1
/dev/sda2       /home           btrfs   noatime,compress=lzo,subvol=@home       0       2
/dev/sda3       none            swap    sw                                      0       0
tmpfs           /tmp            tmpfs   noatime,mode=1777                       0       0

SDA is a 256 GB SSD. It contains my EFI system partition, a swap partition, and a BTRFS partition with two subvolumes. SDB is a 1 TB hard disk. It contains a single EXT4 partition. I've moved /tmp to a tmpfs file system, which stores it completely in RAM and not on the disk. Don't do that with /var/tmp, because stuff there is intended to persist between reboots.

**bobbicat** · Jul 02, 2014, 12:06 PM

Well that was quite an adventure - I'm not sure exactly where I've been but I'm more or less back where I started.
I've got a GPT partition table so I've been using GParted Live installed on a pen drive - it has been a very useful partition editor.
I started by creating a RAID 0 array with btrfs formatting as suggested. I don't know if I got it right or horrendously wrong but I soon realised I was very much out of my depth. I installed and reinstalled a couple of times but the complexities of btrfs and RAID had me totally perplexed. Google was giving me information years out of date and the manual looked like something written in Urdu by a Chinese Mandarin.
So I cut back to a simple reinstall, formatting with EXT4 and leaving BTRFS until I understood RAID a little better.
I successfully set up RAID 0 but after reading about how it could lose my data, I decided to use another spare drive and try RAID 5 instead.
It took some time to completely set up but I got there in the end. I can see how useful this would be for server computing with loads of data but for my PC with a paltry few (but precious) files it seems like overkill.
I've been messing with this thing for about a week now and my conclusion is that I don't need RAID on my desktop. I would recommend anyone, with spare drives and the time, to try it though. It was an interesting and educational experience. If I ever want to set up a server I have a better idea now of what would be involved.
The other suggestion, using BTRFS, will be my next project, but after all that frenetic computerization over the last few days, I am going to lean back and let the world float gently by for a while.

I asked some questions at the beginning of this thread.
I very much like the idea of a 'leapfrog partition' and will be adopting that strategy at the next Release Upgrade. Also having a separate install on another drive looks interesting, there's been many a time the fastest solution to a problem has been to blitz a drive and start over, that would make things so easy.
I've also taken on board the fact that the panic about SSD's is just froth. I understand that they can be treated as fast hard drives deserve to be treated. I've got trim covered using the default edited /etc/cron.weekly/fstrim.
I've sorted my swapfile, using 8Gb now, as you say I'm sure that is more than adequate.
I'm happier now about my /tmp file setup. Wandering in the world of Google can be a confusing experiece for an ignoramus like myself. There are so many self declared experts with conflicting and sometimes out-dated information. Many a time its grit your teeth and try it, then prepare to attempt a recovery.
I've had too many 'learning experiences' not to have a backup system. I remember many years ago when I used to dual boot. The 'other operating system' suggested that a minor adjustment needed to be made. I allowed it and promptly irrecoverably lost all the files I had worked on and accumulated. Everything was mangled and after several attempts at recovery I had to give up. Since then its been single boot all the way. The other operating system went out the window - all I ever did in those days was defragment, virus check, hunt for drivers and reinstall because of a corrupt registry.
Using rdiff-backup with a couple of tiny scripts I have backups hourly and also at shutdown and reboot. The scripts also dump increments older than two days, so the file stays lean.

Your answers to my questions have been both stimulating and useful. Thanks to all three of you, oshunluvr, mr_raider and SteveRiley. I've now got a system that I feel is better suited to its purpose and I am inspired to venture further and discover more.
I intend to read up on BTRFS and implement it when I feel more aware of how it works. I am very interested. I will also try to find out more about fstab options.

I'm going to mark this thread 'solved' as you have covered all the points, thank you.

**oshunluvr** · Jul 02, 2014, 01:40 PM

Search my other threads here on btrfs, even that info is a bit dated, but it still applies. Honestly, I'm perplexed at what issues you might have had (a new thread when you're ready to talk about it

). Other than having to install btrfs-tools and not being able to boot directly to a BTRFS raid, I can't imagine what issues you ran into. No matter, at least you're arranged better and up and running.

No doubt you picked up some knowledge and confidence along the way - exactly how most of us got where we are, too.

One point in your above post: AFAIK, the "G" in Gparted refers to "Graphical" as in "Graphical Partition Editor" and really has nothing to do with MBR vs. GPT disks. GParted works on either partition table type. If you venture into the non-graphical world of disk partition manipulation (which I recommend as a learning experience) you will want to use "gdisk" - as in "GPT fdisk" - for GPT drives and good old "fdisk" for MBR drives. I realize this is a minor point, but better to get the names/terms right from the get-go to avoid confusion later on.

I think I can speak for Steve, Mr. Raider, and myself and say "You're Welcome" for the help and we're glad we contributed. That's why we troll here to begin with

I'll look forward to your BTRFS thread some time in the future!

**bobbicat** · Jul 03, 2014, 04:02 AM

I promise to create a btrfs thread when I have started using the system, I'm sure this will be a good place to get answers to the inevitable questions that will ensue.

In the mean time I've created a thread outlining my simple backup method. It isn't comprehensive, but in my view any backup method is better than none.
It is only when things have truly gone pear shaped and you have lost important data that you realize that being prepared is a good policy.

The thread is entitled 'Don't have regrets - have backups - using rdiff-backup'

Announcement

UEFI, SSD's and partitioning

UEFI, SSD's and partitioning

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment