[1] Example from 2007 https://www.linuxquestions.org/questions/debian-26/debian-in... [2] Example from around 1997 https://tldp.org/HOWTO/html_single/Partition/#SwapSize
[1] Example from 2007 https://www.linuxquestions.org/questions/debian-26/debian-in... [2] Example from around 1997 https://tldp.org/HOWTO/html_single/Partition/#SwapSize
I also (vaguely) remember some people putting build partitions closer to the front.
still avoid hitting that thing at any cost. Memory is pretty quick stuff.
If you assume that swap is a crutch the ideally won't be used or if it is used it is either for a short period only (due a to temporary overallocation) or for pages that are very rarely (if ever) used again (chunks of code & data that get loaded by then only certain configurations ever touch again), then you want to keep the fastest part of the drive for things that are going to be assessed regularly (your root partition for instance) in normal operation. For the occasional write & read of swap it makes little difference, and once you are properly thrashing pages to & from swap the time cost of head movements completely dwarfs any difference made by the actual location of the swap area (the heads will be spending most of their time in/near it anyway in such circumstances).
If you were relying on swap for general operations because the amount of RAM you'd need otherwise was just far too expensive, then you have a workload that warrants custom partitioning, to put it elsewhere but the end or ideally on another drive if you could afford a second.
If speed is an issue then you want it near the most commonly accessed data. Back when I used to have to think about these things much at all my general default arrangement was “boot, LVM” and within LVM “root, var, swap, homes, other data”. Swap being in the middle makes resizing in-place something I wouldn't generally consider, but if I needed more temporarily the extra would be created as a swap file (with lower priority than the partition) instead and/or better on a different drive (with higher priority, moving the main swapping load off the system drive).
Another, though less commonly useful, reason might be because it is easier to resize that way: if you need more than shrink the filesystem and add an extra swap area in the newly freed space.
> that also made moving an existing installation to a larger disk more complicated, since you couldn't just resize the os partition, you had to delete and then recreate swap
That isn't really a significant issue though, you shouldn't need swap while performing that operation (unless you are somehow moving the root filesystem around live) so stopping swap isn't going to be a problem (and a user capable of safely performing such a move at all will be able to handle the three extra commands needed). Assuming that you move everything first then resize, my preference would instead to be to move and resize individual partitions instead of moving everything so swap doesn't need to be moved and resized at all.
Yes. You expect the seek time to dominate performance.
The reason that the swap was faster when placed at the beginning is likely because the filesystem is mostly empty and so the allocated portion is at the beginning of the partition.
If the filesystem was near capacity and the files are distributed throughout, then you would expect the performance of the swap at the end and the swap at the beginning to start to converge.
If you think about it extending a filesystem is pretty easy: you just have to write in the filesystem control structures that you have more blocks available to store data than what originally planed. The problem of course is shrinking, since you have to relocate the blocks that goes beyond the new partition size.
Probably not an issue for a desktop since no one would want to use it under heavy swap all the time, but for a server no one pays much attention to... maybe.
SWAP on SSD or NVMe is still miles better than HDD, you can notice the difference when the swap is being used.
Turns out that the app grew huge over time and the machine would swap like crazy and would eventually slow to a crawl. The machine was already maxed out on RAM, so we added a service to restart the app twice a week. Finance said it took hours off their month-end work, they thought the app was just slow.
You can also monitor swapping activity in iotop. If need be, this can also be written on third party tools, the interfaces are exposed by the kernel after all.
Oh and you can use the modern PSI monitoring of the kernel to measure how much pressure a subsystem is experiencing, so you can restart services way before you'd even notice the swapping on other tools.
At least in my experience, it's pretty hard to actually gauge memory use, but swap use makes a reasonable gauge most of the time. There are certainly many use cases where the swap use ends up not being a useful gauge though.
Which means that CDs and DVDs are always read at the same speed, no matter where the laser / read head is.
Only those who really worked with hard drives noticed the speed increase at the inner ring.
This is only true for "slow" drives, CD drives faster than 12x typically use CAV and DVD drives >= 8x use CAV or Z-CLV (sometimes P-CAV).
Where's the intuitive start or end of the disk? I knew the answer was the tracks furthest from the center. Whether that was the beginning or end, I couldn't tell you.