Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

What is better for performance? A partition closer to the inside of the disk will have slower access times, and we must wait for the drive to switch between the OS and swap partitions.

On the other hand, a swap partition bypasses all of the filesystem allowing writes to the disk directly, which can be faster than a file.

What is the performance trade off?

How much does having a fixed size swapfile make a difference?

Is it a case that it will be longer to change to the swap partition, but performance will be better while it is on the swap partition that if it had been a swap file?

share|improve this question
Just out of curiosity. Can you provide system details like kernel version, RAM, partition and filesystem scheme? –  viky Jun 15 '09 at 4:10
On what OS are you looking for ? –  Mathieu Chateau Jun 15 '09 at 6:00
For Linux info, see lkml.org/lkml/2005/7/7/326 –  Adam Monsen Mar 28 '12 at 22:40

6 Answers 6

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:

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.

share|improve this answer
Modern versions of swapon will outright refuse to work with sparse files formatted as swap, citing that the file has holes. –  Tim Post Apr 26 '11 at 2:30
  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.

share|improve this answer

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.

share|improve this answer
Why would a partition be better performance wise, when access times can be more of a factor for delay? –  Bill Gray Jun 15 '09 at 3:23
Because using a file may require more head movements, because when finding the page to read/write the data could be anywhere on the filesystem so fs structures may need to be searched whereas with a swap partition each page will be in a known location within the partition. This makes access time (as apposed to bulk throughput) a differentiating factor. –  David Spillett Jun 15 '09 at 7:26

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.

share|improve this answer
A swap file does not become fragmented, as the kernel uses a direct mmap approach and will never grow or shrink the file. +1 though for your comment on virtualization: it often does not matter. –  parasietje Mar 20 '14 at 18:13

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.




share|improve this answer
Neither of those links really explain the reasons behind their decisions however. –  Bill Gray Jun 15 '09 at 3:47
The reasoning is that the file will have its underlying filesystem overload. If you create a file it could be fragmenged. and depending on the file which is being cached on swap, the reads could be slow as compared to an entire partition which is a swap file system in its own. –  viky Jun 15 '09 at 4:04
Tried to dig further and found relative article on wiki. Just to assist you there are few swap tuning parameters which you can check. Also check the explanation under implementation for linux. Might help. en.wikipedia.org/wiki/Paging –  viky Jun 15 '09 at 4:08
Followed one of the citations on the above mentioned wiki link and found an interesting thread about same issue. Might want to check that out. lkml.org/lkml/2005/6/28/427 –  viky Jun 15 '09 at 4:29
I mentioned the filesystem overload in my question, but it is not as much a performance block as having a partition near the inner disk is. That delay would be great than the filesystem overhead. –  Bill Gray Jun 15 '09 at 5:00

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.

share|improve this answer
Can you provide any sort of justification for your claims? This seems rather anecdotal. –  austinian Jul 15 at 3:03

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.