Swap partition vs swap file
Mike Richards
partition and a swap file?
An exhaustive Google search turns up several conflicting answers. The
consensus seems to be that a swap partition is more efficient than a
swap file, but whether or not the difference is noteworthy is never
definitively answered.
For the sake of argument, let's assume you've got modern hardware with
ample RAM and a recent kernel (a late 2.4.x or 2.6.x), and that under
normal conditions you never seeing more than 50-100MB of swap used.
Given this situation, is there any significant performance or
stability advantage to using a swap partition instead of a swap file?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Andrew Morton
>
> Given this situation, is there any significant performance or
> stability advantage to using a swap partition instead of a swap file?
In 2.6 they have the same reliability and they will have the same
performance unless the swapfile is badly fragmented.
Marat Buharov
"...Note that a swap file must not contain any holes (so, using cp
(1) to create the file is not acceptable)..."?
If swap file will be fragmented it will contain holes.
Or what type of holes can cp(1) can create, which are not usefull for mkswap(8)?
2005/6/29, Andrew Morton <ak...@osdl.org>:
Douglas McNaught
> Hmm, but what about tells mkswap(8) tells:
> "...Note that a swap file must not contain any holes (so, using cp
> (1) to create the file is not acceptable)..."?
>
> If swap file will be fragmented it will contain holes.
No, holes are actual missing blocks (which are read as zeros) while
fragmentation just means the blocks of the file are not contiguous on
disk.
-Doug
Mike Richards
> > stability advantage to using a swap partition instead of a swap file?
>
> In 2.6 they have the same reliability and they will have the same
> performance unless the swapfile is badly fragmented.
Thanks for the reply -- that's been bugging me for a while now. There
are a lot of different opinions on the net, and most of the
conventional wisdom says use a partition instead of a file. It's nice
to hear from an expert on the matter.
Three more short questions if you have time:
1. You specify kernel 2.6 -- What about kernel 2.4? How less reliable
or worse performing is a swapfile on 2.4?
2. Is it possible for the swapfile to become fragmented over time, or
does it just keep using the same blocks over and over? i.e. if it's
all contiguous when you first create the swapfile, will it stay that
way for the life of the file?
3. Does creating the swapfile on a journaled filesystem (e.g. ext3 or
reiser) incur a significant performance hit?
Thanks again. It's much appreciated.
Andrew Morton
>
> > > Given this situation, is there any significant performance or
> > > stability advantage to using a swap partition instead of a swap file?
> >
> > In 2.6 they have the same reliability and they will have the same
> > performance unless the swapfile is badly fragmented.
>
> Thanks for the reply -- that's been bugging me for a while now. There
> are a lot of different opinions on the net, and most of the
> conventional wisdom says use a partition instead of a file. It's nice
> to hear from an expert on the matter.
>
> Three more short questions if you have time:
>
> 1. You specify kernel 2.6 -- What about kernel 2.4? How less reliable
> or worse performing is a swapfile on 2.4?
2.4 is weaker: it has to allocate memory from the main page allocator when
performing swapout. 2.6 avoids that.
> 2. Is it possible for the swapfile to become fragmented over time, or
> does it just keep using the same blocks over and over? i.e. if it's
> all contiguous when you first create the swapfile, will it stay that
> way for the life of the file?
The latter. Create the swapfile when the filesystem is young and empty,
it'll be nice and contiguous. Once created the kernel will never add or
remove blocks. The kernel won't let you use a sparse file for a swapfile.
> 3. Does creating the swapfile on a journaled filesystem (e.g. ext3 or
> reiser) incur a significant performance hit?
None at all. The kernel generates a map of swap offset -> disk blocks at
swapon time and from then on uses that map to perform swap I/O directly
against the underlying disk queue, bypassing all caching, metadata and
filesystem code.
Coywolf Qi Hunt
> Mike Richards <mrmik...@gmail.com> wrote:
> >
> > > > Given this situation, is there any significant performance or
> > > > stability advantage to using a swap partition instead of a swap file?
> > >
> > > In 2.6 they have the same reliability and they will have the same
> > > performance unless the swapfile is badly fragmented.
> >
> > Thanks for the reply -- that's been bugging me for a while now. There
> > are a lot of different opinions on the net, and most of the
> > conventional wisdom says use a partition instead of a file. It's nice
> > to hear from an expert on the matter.
> >
> > Three more short questions if you have time:
> >
> > 1. You specify kernel 2.6 -- What about kernel 2.4? How less reliable
> > or worse performing is a swapfile on 2.4?
>
> 2.4 is weaker: it has to allocate memory from the main page allocator when
> performing swapout. 2.6 avoids that.
>
> > 2. Is it possible for the swapfile to become fragmented over time, or
> > does it just keep using the same blocks over and over? i.e. if it's
> > all contiguous when you first create the swapfile, will it stay that
> > way for the life of the file?
>
> The latter. Create the swapfile when the filesystem is young and empty,
I guess/hope dd always makes it contiguously.
> it'll be nice and contiguous. Once created the kernel will never add or
> remove blocks. The kernel won't let you use a sparse file for a swapfile.
>
--
Coywolf Qi Hunt
http://ahbl.org/~coywolf/
Bernd Eckenfels
> I guess/hope dd always makes it contiguously.
No, it is creating files by appending just like any other file write. One
could think about a call to create unfragmented files however since this is
not always working best is to create those files young or defragment them
before usage.
Gruss
Bernd
Jeremy Nickurak
> No, it is creating files by appending just like any other file write. One
> could think about a call to create unfragmented files however since this is
> not always working best is to create those files young or defragment them
> before usage.
Except that this defeats one of the biggest advantages a swap file has
over a swap partition: the ability to easilly reconfigure the amount of
hd space reserved for swap.
--
Jeremy Nickurak <at...@lkml.spam.rifetech.com>
Helge Hafting
You can still reconfigure the amount of swap by creating more swapfiles
later - you merely risk a fragmented file. Keep your filesystems only
half full though, and it won't be a big problem.
:-)
Helge Hafting
Wakko Warner
Of course, now this begs the question: Is it possible to create a large file
w/o actually writing that much to the device (ie uninitialized). There's
absolutely no reason that a swap file needs to be fully initialized, only
part which mkswap does. Of course, I would expect that ONLY root beable to
do this. (or capsysadmin or whatever the caps are)
--
Lab tests show that use of micro$oft causes cancer in lab animals
Eric Sandall
Hash: SHA1
On Fri, 8 Jul 2005, Wakko Warner wrote:
> Jeremy Nickurak wrote:
>> On ven, 2005-07-08 at 03:22 +0200, Bernd Eckenfels wrote:
>>> No, it is creating files by appending just like any other file write. One
>>> could think about a call to create unfragmented files however since this is
>>> not always working best is to create those files young or defragment them
>>> before usage.
>>
>> Except that this defeats one of the biggest advantages a swap file has
>> over a swap partition: the ability to easilly reconfigure the amount of
>> hd space reserved for swap.
>
> Of course, now this begs the question: Is it possible to create a large file
> w/o actually writing that much to the device (ie uninitialized). There's
> absolutely no reason that a swap file needs to be fully initialized, only
> part which mkswap does. Of course, I would expect that ONLY root beable to
> do this. (or capsysadmin or whatever the caps are)
That would make the swap file fragment as it's used, instead of
allocating one big file (the entire file) at once (and hopefully get
one contiguous chunk of the disk).
- -sandalle
- --
Eric Sandall | Source Mage GNU/Linux Developer
er...@sandall.us | http://www.sourcemage.org/
http://eric.sandall.us/ | SysAdmin @ Inst. Shock Physics @ WSU
http://counter.li.org/ #196285 | http://www.shock.wsu.edu/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
iD8DBQFC0FbfHXt9dKjv3WERApKjAJ9ZObnrYWCmTyZW0ChggtgGjTKIvQCfbnvm
/U4zfjTYqMxEd5vmIRe1wbM=
=smCj
-----END PGP SIGNATURE-----
Wakko Warner
> >Of course, now this begs the question: Is it possible to create a large
> >file
> >w/o actually writing that much to the device (ie uninitialized). There's
> >absolutely no reason that a swap file needs to be fully initialized, only
> >part which mkswap does. Of course, I would expect that ONLY root beable to
> >do this. (or capsysadmin or whatever the caps are)
>
> That would make the swap file fragment as it's used, instead of
> allocating one big file (the entire file) at once (and hopefully get
> one contiguous chunk of the disk).
You misunderstood entirely what I said.
--
Lab tests show that use of micro$oft causes cancer in lab animals
Bernd Eckenfels
> You misunderstood entirely what I said.
There is no portable/documented way to grow a file without having the file
system null its content. However why is that a problem, you dont create
those files very often. Besides it is better for the OS to be able to asume
that a page with zeros in it is equal to the page on fresh swap.
Gruss
Bernd
Wakko Warner
> In article <20050710014...@animx.eu.org> you wrote:
> > You misunderstood entirely what I said.
>
> There is no portable/documented way to grow a file without having the file
> system null its content. However why is that a problem, you dont create
> those files very often. Besides it is better for the OS to be able to asume
> that a page with zeros in it is equal to the page on fresh swap.
So are you saying that if I create a swap partition it's best to use dd to
zero it out before mkswap? If no, then why would a file be different? I
know there's no documented way to create a file of given size without
writing content. I saw windows grow a pagefile several meg in less than a
second so I'm sure that it doesn't zero out the space first.
As far as portable, we're talking about linux, portability is not an issue
in this case. I myself don't use swap files (or partitions), however, there
was a project I recall that would dynamically add/remove swap as needed.
Creating a file of 20-50mb quickly would have been beneficial.
--
Lab tests show that use of micro$oft causes cancer in lab animals
Bernd Eckenfels
> So are you saying that if I create a swap partition it's best to use dd to
> zero it out before mkswap?
Nope I did not. However I dont know of any other shell tool which can do it
that easyly.
> As far as portable, we're talking about linux, portability is not an issue
> in this case.
Portability across Filesystems.
Gruss
Bernd
Helge Hafting
>Bernd Eckenfels wrote:
>
>
>>In article <20050710014...@animx.eu.org> you wrote:
>>
>>
>>>You misunderstood entirely what I said.
>>>
>>>
>>There is no portable/documented way to grow a file without having the file
>>system null its content. However why is that a problem, you dont create
>>those files very often. Besides it is better for the OS to be able to asume
>>that a page with zeros in it is equal to the page on fresh swap.
>>
>>
You don't need to zero out swapfiles. You can fill them with anything,
even /dev/urandom. Zero-filling may be faster though. A swapfile
is not zero the second time you use it - then it contains leftovers
from last time.
>
>So are you saying that if I create a swap partition it's best to use dd to
>zero it out before mkswap? If no, then why would a file be different? I
>know there's no documented way to create a file of given size without
>writing content. I saw windows grow a pagefile several meg in less than a
>second so I'm sure that it doesn't zero out the space first.
>
>
Linux doesn't grow swapfiles at all. It uses what's there at mkswap time.
You can make new ones of course - manually.
>As far as portable, we're talking about linux, portability is not an issue
>in this case. I myself don't use swap files (or partitions), however, there
>was a project I recall that would dynamically add/remove swap as needed.
>Creating a file of 20-50mb quickly would have been beneficial.
>
>
You can create 50M quickly - even if it actually have to be written. If
you can't, don't use that device for swap.
Ability to allocate some blocks without actually writing to them is nice
for this
purpose, but current linux filesystems doesn't have an api for doing that.
The necessary changes would touch all existing writeable filesystems, and
that is a lot of work for very little gain. As they say, you don't
create swapfiles
all that often. The time saved on swapfile creation might take a long
time to
make up for the time spent on making, auditing and supporting those
changes.
Helge Hafting
Wakko Warner
> Wakko Warner wrote:
> You don't need to zero out swapfiles. You can fill them with anything,
> even /dev/urandom. Zero-filling may be faster though. A swapfile
> is not zero the second time you use it - then it contains leftovers
> from last time.
I understand this part.
> >So are you saying that if I create a swap partition it's best to use dd to
> >zero it out before mkswap? If no, then why would a file be different? I
> >know there's no documented way to create a file of given size without
> >writing content. I saw windows grow a pagefile several meg in less than a
> >second so I'm sure that it doesn't zero out the space first.
>
> Linux doesn't grow swapfiles at all. It uses what's there at mkswap time.
> You can make new ones of course - manually.
And this part. I've never known linux to grow the swap file. I did try the
sparse one a long time ago. Of course it didn't work.
> >As far as portable, we're talking about linux, portability is not an issue
> >in this case. I myself don't use swap files (or partitions), however,
> >there
> >was a project I recall that would dynamically add/remove swap as needed.
> >Creating a file of 20-50mb quickly would have been beneficial.
>
> You can create 50M quickly - even if it actually have to be written. If
> you can't, don't use that device for swap.
Not all systems can create 50mb in a short time. Especially when the
system/device is under load. Not all systems have multiple disks either.
> Ability to allocate some blocks without actually writing to them is nice
> for this
> purpose, but current linux filesystems doesn't have an api for doing that.
> The necessary changes would touch all existing writeable filesystems, and
> that is a lot of work for very little gain. As they say, you don't
> create swapfiles
> all that often. The time saved on swapfile creation might take a long
> time to
> make up for the time spent on making, auditing and supporting those
> changes.
I hadn't considered this "portability" so I didn't understand at that
point.
--
Lab tests show that use of micro$oft causes cancer in lab animals
Jan Engelhardt
>> You can make new ones of course - manually.
>
>And this part. I've never known linux to grow the swap file. I did try the
>sparse one a long time ago. Of course it didn't work.
I can't remember where exactly I read it but: when swapon is called, a
fixed-size(determined at swapon) bitmap of the swap blocks is generated (to
cope with fragementation of swapfiles).
Can somebody confirm this?
Jan Engelhardt
--