Re: Swap partition vs swap file

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Helge Hafting wrote:
> 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]
  Powered by Linux