[vox-tech] recommended partition scheme for a dual boot windows 7/ubuntu machine?

[Rick Moen]

Note:  I will not be addressing the specific use case the original
poster had in mind of a dual-boot workstation -- and instead detail
a Linux server scheme.  Personally, I think virtual machine solutions
(VirtualBox, VMWare) are almost always far better than dual booting, and
I would urge considering those.


Partition strategy in general is a repeatedly re-argued discussion on
vox-tech.  The deceased equine was last flogged June 2009, methinks.

People merely looking to justify the simplest possible partition layout 
should carefully avoid reading further.  ;->  



Quoting Rod Roark (rod at sunsetsystems.com):

> I try to avoid creating a partition without a good reason.  

Some good reasons (that of course are context-dependent):
http://linuxmafia.com/~karsten/Linux/FAQs/partition.html
(Karsten updated and generally dusted the page since the 2009 iteration
of this discussion.)

I would add (for the specific context of my current server host):  

o  Grouping of filesystems to minimise average HD seek distance 
   (a concern that happily vanishes completely if you switch to SSD, 
   as I will be doing soon)
o  The use of custom fileystem types and mounting options to achieve
   particular per-filesystem administration and performance goals.


In the server /etc/fstab file below, '/boot' is of course vestigial:  I
wouldn't include it in a current build.  Current host has three physical
hard drives:  boot drive sda and mirror pair sdb/sdc ('md' RAID1 set).


# <file system> <mount point>   <type>  <options>       <dump>  <pass>
proc            /proc           proc    nosuid,noexec,nodev  0       0
none            /sys            sysfs   nosuid,noexec,nodev  0       0
tmpfs           /run            tmpfs   defaults             0       0
devtmpfs        /dev            devtmpfs mode=0755,nosuid    0       0
none            /dev/pts        devpts  mode=622        0       0
none            /dev/shm        tmpfs   defaults        0       0
#
/dev/sda7       /               ext3    defaults,errors=remount-ro 0       1
/dev/sda1       /boot           ext2    defaults        0       2
/dev/md3        /home           ext3    nefaults        0       2
/dev/sda8       /recovery       ext3    noauto          0       2
/dev/sda9       /usr            ext2    nodev,ro        0       2
/dev/md4        /usr/local      ext3    defaults        0       2
/dev/sda6       /var            ext2    noatime,nodev,nosuid 0       2
/dev/md1        /var/lib        ext3    nodev           0       2
/dev/md2        /var/spool      ext3    defaults        0       2
/dev/md0        /var/www        ext3    nodev,nosuid    0       2
/dev/sda5       none            swap    sw pri=2        0       0
/dev/sdb8       none            swap    sw pri=1        0       0
/dev/sdc8       none            swap    sw pri=1        0       0

(Note absence of UUID noise.)


Note groupings to minimise disk seeking, which is by far the slowest 
operation a hard disk does.  Such grouping, to the extent successful,
should also reduce wear and extend drive life (less thrashing).

sda ordering:
sda1  /boot
sda5  swap
sda6  /var
sad7  /
sda8  /recovery
sda9  /usr

sdb/sdc mirror pair ordering:
md0       /var/www
md1       /var/lib
md2       /var/spool
sdb8/sdc8 swap
md3       /home
md4       /usr/local

For each spindle, I've grouped text to the swap partition the subtrees 
that take the biggest beating (most frequent disk access) on a server 
system.

/usr is kept normally read-only as a measure to partially protect it
against the system's biggest enemy:  the sysadmin, and his clumsy
thumbs, especially before morning coffee.  There's an apt hook to
remount the fileystem temporarily rw for package operations and then
remount it ro afterwards.  This is also a small last defence against
the dumber types of trojans.

Similar remarks apply to the nodev,nosuid flags.  If a subtree should
never have SUID files or device files, then making them not valid there
is A Good Thing.

Having /var (other than /var/spool and /var/lib) ext2 rather than ext3,
and with the noatime mount option, makes its write performance a
significantly better.  (relatime is often good, especially on SSDs,
depending as usual on context.)


Many 2013 improvements are not present in the above, e.g., tmpfs, and 
the layout resulted from an emergency rushed rebuild in 2008 following 
destruction of my old server in a lightning storm.  There's probably
a small list of other enhancements that would be made in a modern build,
and SSDs make many past tweaks obsolete.  And ext4 / btrfs weren't on
the table back then.

The new hardware will be 100% SSD-based and thus different and simpler.
(No more concern about seek distances.)  I'll proably lean conservative
and go ext4 -- except for /var, which will probably still be ext2 with
noatime, as that's difficult to beat for performance and cuts SSD wear.
Probably no swap at all.


Things I need to look into:

o  Any complications with making sure an all-RAID1 disk array's
   bootloader can boot from either drive.  I know lilo & elilo 
   can handle this.  Can GRUB?  GRUB2?  syslinux?

o  Optimal mdadm '-chunk=NN' values for RAID1 on SSDs.

o  Optimal ext4 block size, stride, and stripe-width for RAID1 on SSDs.

o  Is '-metadata=0.90' still necessary for making an md RAID1 array
   bootable from either drive, or is that just lilo?

o  'data=writeback' on ext4?   (tune2fs -o journal_data_writeback
    /dev/sdxx and change mount options.)



(Sometimes, what 'defaults' means in /etc/fstab differs.  Do 'cat
/proc/mounts' to see what it expanded to on your system.)

Given SSD usage, I'll probably make /tmp be tmpfs (warning: which makes
it non-persistent across reboots).