I saw the following post in another thread and thought it was interesting:
In Linux you create swap partitions, not files. how can you simply create a swap file and use it? I could see this as a Windows trick, but it doesn't seem logical in Linux, based on what I know. Can someone clarify for me?

A bit old...but still good...

http://www.redhat.com/docs/manuals/l...ap-adding.html

Apparently Red Hat knows about it...

-C

So you don't even need to use losetup to attach a loop device to the swap file.

A partition is just an entry in the device table, isn't it? One disk device is pretty much the same as another, regardless of what hardware/software it's instantiated in.

Linux has supported swap files (as well as partitions) for as long as I've been playing with it.
Prior to 2.5, the swap file entailed more overhead because it was a file, and needed additional pathlengh (VFS ??? - I dunno, I never looked). For anybody on 2.6 kernels this is no longer a concern - I/O to swap is now handled directly by the blocklayer driver(s). Same for files and partitions regardless.

Thank you all for your assistance in expansion of my knowledge.

You can create a file for swap space but its not the best solution in many cases because files have a tendancy, on a well used partition, to not end up sequential which generally slows down access time.

Now that I think about it however, I'd like to see a compile time comparison on a machine with little ram and plenty of swap using various file systems, ext2, ext3, ext4, jfs, xfs, reiserfs, etc.

Swap files ain't "files" - they won't fragment with use. Last I looked at the mkswap code it wasn't very friendly, and made no allowance for non-contiguous allocation. IIRC (nowadays) the space map only has the length, and marks any bad blocks within that range. I don't think I'd allow (subsequent) fragmentation within the originally allocated extent that mkswap knew about.

But then, I don't use swap files, so I don't need to worry about that ...

A true swap "file" won't fragment with use but it may be fragmented to begin with. I've done a good bit of work doing file recovery on ext2/3 file systems so I'm pretty familiar with how files are allocated when using a program like dd... especially in the case of a large file (say a gig) and a heavily used file system (been in production for a long time) you very well may end up with a non-contiguous swap file especially if its very large (>1g). I would have to dig around in the code of mkswap to be absolutely positive, but I can't imagine it even caring if every single block used was non-contiguous.... that becomes something the file system has to deal with. Look at the process slow coder is using to generate the swap file... that *IS* a true file on the file system.

It's a moot point for me too, if i'm dipping into the swap on the system I've got more significant issues than how the swap files are function, but shrug, might as well keep it as accurate as possible.