4 ms·

Yes, this was common knowledge, yet back in the day most distro setups still put swap at the end by default for reasons unknown to me. Apart from the speed issu

Yes, this was common knowledge, yet back in the day most distro setups still put swap at the end by default for reasons unknown to me. Apart from the speed issue, 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.

minitoar 5y ago
I thought there was some idea that you wanted core os/app data near the center since you would always be using that.
- ragnese 5y ago
  Yes, that was the argument I remember reading. You put "system" stuff first, then /home if you did a separate partition for it, etc. Swap last because "hopefully you won't be swapping much anyway". I also (vaguely) remember some people putting build partitions closer to the front.
  - actually_a_dog 5y ago
    I think we're also talking about the days when a machine that was swapping extensively was going to be stupidly slow no matter what you did.
    - Filligree 5y ago
      Those days never ended.
      - bee_rider 5y ago
        I put my swap on a nice NVME drive and... still avoid hitting that thing at any cost. Memory is pretty quick stuff.
dspillett 5y ago
> put swap at the end by default for reasons unknown to me 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.
- mtdewcmu 5y ago
  > If speed is an issue then you want it near the most commonly accessed data. 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.
throwawayboise 5y ago
Back in the day you couldn't "just" resize a partition either. At minimum you would need to copy all the data somewhere, recreate the partition, reformat the filesystem, copy the data back. You might need to do this with other partitions also to make room, if you didn't leave any gaps to start with.
- iforgotpassword 5y ago
  True, maybe not back in the day, but ~10 years ago I still used hdds in some machines and resizing was definitely possible and reliable.
  - bradknowles 5y ago
    Some OSes could do that, yes. Rare.
  - Isthatablackgsd 5y ago
    Me too. I remember using Gparted back in Ubuntu Ibex day (looking at the year, 2008ish). Usually OS come with gparted package or it is available via package manager back then.
- alerighi 5y ago
  I checked the man for resize2fs and the copyright notice is from 1998, so I guess that even back in the day was possible to grow ext2 filesystems. Shrinking them I don't know, it's still a feature that not all filesystems supports to this day. 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.

minitoar 5y ago

I thought there was some idea that you wanted core os/app data near the center since you would always be using that.

ragnese 5y ago
Yes, that was the argument I remember reading. You put "system" stuff first, then /home if you did a separate partition for it, etc. Swap last because "hopefully you won't be swapping much anyway". I also (vaguely) remember some people putting build partitions closer to the front.
- actually_a_dog 5y ago
  I think we're also talking about the days when a machine that was swapping extensively was going to be stupidly slow no matter what you did.
  - Filligree 5y ago
    Those days never ended.
    - bee_rider 5y ago
      I put my swap on a nice NVME drive and... still avoid hitting that thing at any cost. Memory is pretty quick stuff.

dspillett 5y ago

> put swap at the end by default for reasons unknown to me 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.

mtdewcmu 5y ago
> If speed is an issue then you want it near the most commonly accessed data. 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.

throwawayboise 5y ago

Back in the day you couldn't "just" resize a partition either. At minimum you would need to copy all the data somewhere, recreate the partition, reformat the filesystem, copy the data back. You might need to do this with other partitions also to make room, if you didn't leave any gaps to start with.

iforgotpassword 5y ago
True, maybe not back in the day, but ~10 years ago I still used hdds in some machines and resizing was definitely possible and reliable.
- bradknowles 5y ago
  Some OSes could do that, yes. Rare.
- Isthatablackgsd 5y ago
  Me too. I remember using Gparted back in Ubuntu Ibex day (looking at the year, 2008ish). Usually OS come with gparted package or it is available via package manager back then.
alerighi 5y ago
I checked the man for resize2fs and the copyright notice is from 1998, so I guess that even back in the day was possible to grow ext2 filesystems. Shrinking them I don't know, it's still a feature that not all filesystems supports to this day. 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.