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 (r...@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). _______________________________________________ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
