Hi,
Here's a question to the fine-tuning gurus.
Yesterday while installing a fresh CentOS server, I wondered how big of a deal the physical position of the swap partition on the disk is.
Here's an example of a simple MBR partitioning scheme on a legacy BIOS machine with a 60 GB SSD:
* /dev/sda1: 500 MB /boot ext2 * /dev/sda2: 4 GB swap * /dev/sda3: 55 GB / ext4
In the old (Slackware) days, I created the partitions manually using fdisk.
Now when I do something similar in Anaconda, I have to reason in terms of mount points. So in a similar order I create the /boot partition, the swap partition and the root partition.
What happens here is that Anaconda will always invert the root and swap partitions and put the swap partition at the end of the disk. So my setup looks like this:
* /dev/sda1: 500 MB /boot ext2 * /dev/sda2: 55 GB / ext4 * /dev/sda3: 4 GB swap
I'd be curious to know what's the reason behind this, and if this kind of configuration detail is really significant.
Cheers,
Niki
On Nov 30, 2020, at 02:35, Nicolas Kovacs info@microlinux.fr wrote:
Yesterday while installing a fresh CentOS server, I wondered how big of a deal the physical position of the swap partition on the disk is.
Here's an example of a simple MBR partitioning scheme on a legacy BIOS machine with a 60 GB SSD:
- /dev/sda1: 500 MB /boot ext2
- /dev/sda2: 4 GB swap
- /dev/sda3: 55 GB / ext4
In the old (Slackware) days, I created the partitions manually using fdisk.
Now when I do something similar in Anaconda, I have to reason in terms of mount points. So in a similar order I create the /boot partition, the swap partition and the root partition.
What happens here is that Anaconda will always invert the root and swap partitions and put the swap partition at the end of the disk. So my setup looks like this:
- /dev/sda1: 500 MB /boot ext2
- /dev/sda2: 55 GB / ext4
- /dev/sda3: 4 GB swap
I'd be curious to know what's the reason behind this, and if this kind of configuration detail is really significant.
When most of us had storage on rotational storage, the fastest, lowest latency access was close to the physical center of the disc, which corresponds to the start of the disk. You’d want swap to be highly responsive in case it was used for active processes.
Now, SSDs don’t have the same physical characteristics, so it doesn’t matter. Also, cloud storage and virtual machines don’t even have real hardware.
The partitioning is handled by different code starting in el7, and this seems to be the logic built in. I feel like it was written to assume that root and swap are on LVM. When it comes to resizing file systems, it might make sense to put the root ext4 at the end of the disk, so it is actually counterproductive to put swap at the end.
-- Jonathan Billings billings@negate.org
On 30.11.2020 13:55, Jonathan Billings wrote:
On Nov 30, 2020, at 02:35, Nicolas Kovacs info@microlinux.fr wrote:
- /dev/sda1: 500 MB /boot ext2
- /dev/sda2: 55 GB / ext4
- /dev/sda3: 4 GB swap
Now, SSDs don’t have the same physical characteristics, so it doesn’t matter. Also, cloud storage and virtual machines don’t even have real hardware.
without hardware neither cloud storage nor virtual machines;
The partitioning is handled by different code starting in el7, and this seems to be the logic built in. I feel like it was written to assume that root and swap are on LVM. When it comes to resizing file systems, it might make sense to put the root ext4 at the end of the disk, so it is actually counterproductive to put swap at the end.
is there a rule that says that the order of the partitions in the partition table corresponds to the order of them itself on disk?
no.
keep in mind, that the order on disk can be something different then the order in the partition table;
Walter
On Mon, Nov 30, 2020 at 03:22:45PM +0100, Walter H. wrote:
is there a rule that says that the order of the partitions in the partition table corresponds to the order of them itself on disk?
no.
keep in mind, that the order on disk can be something different then the order in the partition table;
No, but if my linux distro created out of order partition sequences on initial install I'd throw it in the trash.
On 11/30/20 1:55 PM, Jonathan Billings wrote:
On Nov 30, 2020, at 02:35, Nicolas Kovacs info@microlinux.fr wrote:
- /dev/sda1: 500 MB /boot ext2
- /dev/sda2: 4 GB swap
- /dev/sda3: 55 GB / ext4
I'd be curious to know what's the reason behind this, and if this kind of configuration detail is really significant.
When most of us had storage on rotational storage, the fastest, lowest latency access was close to the physical center of the disc, which corresponds to the start of the disk. You’d want swap to be highly responsive in case it was used for active processes.
Well, actually it is the opposite. The first blocks of the disk are on the edge of the disk and they have better throughput since the the track is longer and contains more data to be read in a single disk revolution (rpm is a constant).
The idea is that you have swap at the beginning because it needs the best performance, then you have your data immediately after.
Having the swap at the end is the worst choice because it is in the slowest zone and it is typically very far from a partially filled data partition at the beginning of the disk, causing a lot of head movement when swapping. The advantage in no-swapping case is minimal, because the swap partition is usually small and having your data starting at 0% of the disk space or at 3% doesn't matter a lot.
Finally, swap throughput really matters when hibernating to disk.
If you have both your swap and filesystems in an LVM volume, you can shuffle and rearrange them on the disk as you prefer without even a reboot (pvmove with explicit extent indications).
Regards.
On Tue, Dec 1, 2020, 2:53 AM Roberto Ragusa mail@robertoragusa.it wrote:
Finally, swap throughput really matters when hibernating to disk.
....
And that's really the only time it should matter on a modern system,. I rarely see /any/ swap in use for normal server or workstation operations
-
John Pierce -
Jonathan Billings -
Nicolas Kovacs -
Roberto Ragusa -
Walter H.