3 ms·
In traditional BSD unixes, swap was always the second partition, very close to the front of the disk, and just behind a small root/boot partition (which was fir
by drewg123 5y ago
In traditional BSD unixes, swap was always the second partition, very close to the front of the disk, and just behind a small root/boot partition (which was first, presumably due to bootstrapping needs).
Looks like the old timers knew what they were doing :)
- kijin 5y agoI still do that with my Linux boxes. A small /boot goes first, followed by swap, /, and finally the partition that will contain the majority of the data (usually /var or /home). This arrangement has advantages even in the age of VMs and SSDs. If I want to change to a larger disk or array (or resize the virtual disk), I can simply extend the last partition where the extra space is most likely to be needed. If swap was last, it would get in the way. On the other hand, if I needed more swap, I could just add a swapfile somewhere.
- mkl95 5y agoI've always assumed this to be the proper way to do things, and it's still what I do when I'm asked to configure a new VM. If it ain't broke, don't fix it.
- 5e92cb50239222b 5y agoswapoff + fdisk + mkswap + swapon takes two minutes tops. I much prefer that to partition "fragmentation".
- chousuke 5y agoI have the UEFI/boot partition followed by an LVM PV. If it's a VM, data disks just get the whole disk, though I still usually set up LVM because it enables stuff like live storage migrations. I've actually had to do those more than once in production; one migration involved moving several terabytes of data used by a hardware server from an aging SAN onto physical disks and iSCSI. It required no downtime. I haven't really had to worry about partitioning on any Linux machine I manage for over a decade thanks to LVM; I just create volumes based on what makes sense for the applications hosted on the servers.