6 ms·
I believe this was kind of obvious 15-25 years ago [1] . That was in THE basic tutorial [2]. Those were simpler days. It was hard to build something big by you
by szszrk 5y ago
I believe this was kind of obvious 15-25 years ago [1] . That was in THE basic tutorial [2]. Those were simpler days. It was hard to build something big by yourself. Now it's easier, but now we are learning just API's to API's that provision our hardware and software :) So much current dev and ops knowledge will be useless in a few years, yet I could easily use a book from 1970' that was recommended here one day, to learn and use some basic AWK nowadays.
[1] Example from 2007 https://www.linuxquestions.org/questions/debian-26/debian-install-swap-partition-516216/#post2571506 https://www.linuxquestions.org/questions/debian-26/debian-in...
[2] Example from around 1997 https://tldp.org/HOWTO/html_single/Partition/#SwapSize https://tldp.org/HOWTO/html_single/Partition/#SwapSize
- iforgotpassword 5y agoYes, 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 agoI thought there was some idea that you wanted core os/app data near the center since you would always be using that.
- ragnese 5y agoYes, 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 agoI 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.
- 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 agoBack 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 agoTrue, 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 agoSome OSes could do that, yes. Rare.
- Isthatablackgsd 5y agoMe 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 agoI 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.
- zaarn 5y agoWell, with modern NVMe and SSD, the "where on the disk is my swap file" begins to matter less. Even at my workplace, any VM needing swap has it's OS disk put on NVMe/SSD, simply because having the user even think a second about this isn't worth the time. On NVMe/SSD, the placement simply doesn't matter, memory becomes non-linear.
- Johnny555 5y agoBut then it becomes a question of "Do I want to put swap on this drive" at all? I don't know the endurance of modern NVME drives, but if you can write 1 PB before wearing out the drive at a sustained 100MB/sec, you can wear out the drive in less than 4 months if you let your system run under heavy swap. 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.
- zaarn 5y agoAs someone who has servers with swap on NVMe; it barely matters. Sustained swap thrashing is a bad scenario no matter how you put it and it'll just tank performance. Get more RAM. SWAP I/O should never have any sustained background level, it should ideally only spike every few minutes or so and remain low level to zero otherwise. SWAP on SSD or NVMe is still miles better than HDD, you can notice the difference when the swap is being used.
- Johnny555 5y agoBut that assumes that someone notices the swap -- when I was new at a former last job, I asked why the drive activity light was always on on the server marked "finance". The answer was "Who knows!? That's some special software that finance uses, when it gets slow they tell us and we reboot it". It had been like that for more than a year. 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.
- actually_a_dog 5y agoIsn't it intuitively obvious, though? At the beginning of the disk, the radial velocity of each sector is much higher than at the end of the disk. It stands to reason you should want your swap file to be where it can be most quickly accessed, and that higher radial velocity should translate directly into lower seek times.
- dragontamer 5y agoNot really. The physical disks used most at that era were CDs and DVDs. Both of which have angular recording. 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.
- kevin_thibedeau 5y agoLater optical drives employed constant speed spindles.
- folmar 5y ago> CDs and DVDs are always read at the same speed, no matter where the laser / read head is. 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).
- meragrin_ 5y ago> Isn't it intuitively obvious, though? At the beginning of the disk 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.