Partitioning scheme

[Fratyr]

Hello.

I'm trying a new way of partitioning my system. Tired of 3 primary disks.

I want to try and do something like that (separate):
/ - root
/boot
/swap
/var
/opt
/usr
/tmp
/home

All these directories in a separate partition.

Which should stay primary, what should go to extended and be a logical under extended?

Thanks

[frostschutz]

linux does not care about primary vs. logical so you can do what ever

may I suggest you use LVM for your partitioning needs, especially if you're planning a lot of partitions, LVM gives you a lot of flexibility and comfort in that it allows you to resize partitions without moving all the other partitions around

[Fratyr]

Many thanks for your help and fast answer. I'll use LVM as you suggested.

[cach0rr0]

btrfs does most of not all of that natively, if you're feeling adventurous.

as an example

(Just to be clear, vda instead of sda has nothing to do with btrfs here; it's a driver thing, because I'm using the virtio block driver under KVM )

Code: Select all

# <fs>                  <mountpoint>    <type>          <opts>          <dump/pass>

# NOTE: If your BOOT partition is ReiserFS, add the notail option to opts.

/dev/vda1               /boot           ext2            noauto,noatime  1 2
/dev/vda3               /               ext3            noatime         0 1
/dev/vda2               none            swap            sw              0 0
/dev/vda4               /tmp            btrfs           subvol=tmp,nodev,noexec,nosuid,noatime  0 2
/dev/vda4               /usr            btrfs           subvol=usr,nodev,noatime,compress  0 2
/dev/vda4               /var            btrfs           subvol=var,noatime 0 2
/dev/vda4               /opt            btrfs           subvol=opt,nosuid,noatime  0 2
/dev/vda4               /home           btrfs           subvol=home,nodev,nosuid,noatime,compress  0 2

# glibc 2.2 and above expects tmpfs to be mounted at /dev/shm for 
# POSIX shared memory (shm_open, shm_unlink).
# (tmpfs is a dynamically expandable/shrinkable ramdisk, and will
#  use almost no memory if not populated with files)
shm                     /dev/shm        tmpfs           nodev,nosuid,noexec     0 0

[Mike Hunt]

/var/tmp is also nice to have as a seperate partition.

That's where, by default, all your ebuilds are emerged.

Having it on a partition gives you more flexibility, if you wish to play with it down the road.

[GWilliam]

#NULL

[cach0rr0]

Does it really matter?

In the 1990s, I used to create separate partitions for /, /boot, /var, /tmp, and /home. On some systems, I put /usr on a separate partition.

For the past decade or so, though, I've been putting the whole system (except for swap, of course) on one big filesystem. I see no reason to bother with separate partitions unless you're in a situation in which inodes are in danger of being used up (if you're running an e-mail server or perhaps an FTP server with a very large number of smallish files).

mount opts. What makes sense for one might not make sense for another. And mounting /tmp as noexec,nosuid is a must IMHO

If you're particularly paranoid, putting /boot on a separate filesystem is arguably a good idea, but other than that, why bother with splitting these things up on separate partitions? With hard disk drive latency, seek times, et cetera being as low as they are these days, why bother unless you have a tremendous amount of churn going on in /var or /tmp?

Disk I/O would not be improved by putting var||tmp on a separate partition. Separate physical volume, yes, separate partition no. There is no advantage to this.

Could end up with disk space gobbled up in the case of a mail routing loop or some such; separate partition avoids this. Could end up with logs that aren't rotated, that you don't catch, and there you are.
And again there's the matter of mount opts.

[goofus]

Does it really matter?

In the 1990s, I used to create separate partitions for /, /boot, /var, /tmp, and /home. On some systems, I put /usr on a separate partition.

For the past decade or so, though, I've been putting the whole system (except for swap, of course) on one big filesystem. I see no reason to bother with separate partitions unless you're in a situation in which inodes are in danger of being used up (if you're running an e-mail server or perhaps an FTP server with a very large number of smallish files).

If you're particularly paranoid, putting /boot on a separate filesystem is arguably a good idea, but other than that, why bother with splitting these things up on separate partitions? With hard disk drive latency, seek times, et cetera being as low as they are these days, why bother unless you have a tremendous amount of churn going on in /var or /tmp?

Why not just put the whole system on the same partition?

I suggest boot and tmp on separate partitions because of security.

Also having different partitions for directories is good to apply quotas. Having quotas on home is good but you don't need quotas on all directories (like usr, opt, etc..)

[depontius]

At a very minimum, I keep /home on a separate partition, so it can survive a complete reinstall.

Of late, I've been using:
/boot
/
/var
/home
<swap>

Then it gets ticklish, because I'm going after "activity-based" partitioning. I try to keep everything that's really active - at least the system-level stuff, on /var. The biggies that aren't there already are /tmp and /usr/portage. So I have for instance /var/roottmp and /var/usrportage, and bind-mount them to /tmp and /usr/portage, respectively. That way, / is read-mostly and /var is heavily read-write. Ext3 can both fragment and defragment through use. My hope has been that this separation would be beneficial.

My other thought has been to move to ext4, and drop back to /boot, /, /home, and <swap>, because I'm under the impression that ext4 should handle such things much better.