swap partition vs file for performance?

1. On hard disks, throughput and seeking is often faster towards the beginning of the disk, because that data is stored closer to the outer area of the disk, which has more sectors per cylinder. Thus, creating the swap at the beginning of the disk might improve performance.

2. For a 2.6 Linux kernel, there is no performance difference between a swap partition and an unfragmented swap file. When a swap partition/file is enabled by swapon, the 2.6 kernel finds which disk blocks the swapfile is stored on, so that when it comes time to swap, it doesn't have to deal with the filesystem at all.

Thus, if the swapfile isn't fragmented, it's exactly as if there were a swap partition at its same location. Or put another way, you'd get identical performance if you used a swap partition raw, or formatted it with a filesystem and then created a swapfile that filled all space, since either way on that disk there is a contiguous region used for swapping, which the kernel uses directly.

So if one creates the swapfile when the filesystem is fresh (thus ensuring it's not fragmented and at the beginning of the volume), performance should be identical to having a swap partition just before the volume. Further, if one created the swapfile say in the middle of the volume, with files on either side, one might get better performance, since there's less seeking to swap.

On Linux, if the swapfile is created unfragmented, and never expanded, it cannot become fragmented, at least with normal filesystems like ext3/4. It will always use the same disk blocks, which are contiguous.

I conclude that about the only benefit of a dedicated swap partition is guaranteed unfragmentation when you need to expand it; if your swap will never be expanded, a file created on a fresh filesystem doesn't require an extra partition.

Actually it doesn't make a lot of difference as long as you don't use sparse files.

Creating a "normal" file with dd will allocate the file (if at all possible) in a single run, while creating a sparse file will tell you that you have a 10GB file lying around but not actually using up all the space. I'm not quite sure wether mkswap won't allocate the space anyway but typically a swap file will grow in time and thus won't allocate a continous sector (as in part of the disk) but rather allocate blocks as needed which lead to fragmentation over time (of course depending on your usage of the disk)

Internally the Linux kernel will access the underlying blocks of a swap file more or less directly - I can't find the link right now what happens under the hood, you have to trust me on this one unless someone will find something more official. All I can come up with right now is:

• a discussion on slashdot
• the wikipedia paging article
• some FAQ on ubuntu

this all applies to the 2.6 line of Linux kernels only.

If you want optimal performance (and what is that, really?... swapping is slow, period. Increase RAM so that you don't swap for best performance), you would want to use a partition.

This is an interesting question and have been reading a lot about the same. Generally a swap partition is better than a file due to the underlying filesystem. But if you are always in need to increase the size of your swap then file is a better option. Untill kernel 2.4 it was considered that a swap partition is faster than a file, but now with the improvements of kernel 2.6 , the performances are almost the same.

Something I found on internet as well.

http://www.go2linux.org/swap-file-vs-swap-partition

and

http://www.sunmanagers.org/pipermail/summaries/2005-November/006913.html

The thinking at our work is that since a Swap file can become fragmented, and fragmentation slows swap access, a partition is a better approach. Of course, defining a staticly sized swapfile does much the same thing but this just seems subjectively neater.

Is this approach the one true way? Probably not, as the practice was established close to 10 years ago. The only major change in drive technology in the intervening years is the complexity of the RAID controllers we use (we're not rich enough for SSD's yet). The increase in drive sizes means that the swap partition we create is closer to the start of the drive than it was back when 18GB drives were shipping standard, so swap speeds are even faster than they were in olden days.

Of course, on our ESX-based Windows systems, position of the swap file is completely, completely moot. There are so many layers of virtualization between the swap file and the physical disk platters that it just doesn't matter. But we keep it on a separate partition because that's just the standard.

I think at the stage we're at now, unless you're running a laptop with a configuration that writes the data to the swap when it suspends/sleeps, swap should really be considered "last resort". Your best bet is to put enough RAM in a box so that it never pages to disk.

That being said, a partition is probably the better way, performance wise, though a file is more flexible. Just make sure that it's on a 7200+ RPM spindle.

Using a swap file might use a bit extra memory for the file-to-memory-translation. We are talking about less than 1MB memory per 1GB swap. The file system cache does NOT cache swapped data, only the organisational data, which should be most of the extra memory requirements.

Besides that I doubt you will lose any reasonable performance except maybe once in a 1000 times a single additional head seek.

Funny fact, using zswap together with a dynamically expanding swap file results in an impressive speed up on swap operations at very little costs while unused.