Re: Maximum x86 swap partition size ?

From: Andries . Brouwer
Date: Mon Aug 18 2003 - 13:43:49 EST


> Any reason you haven't responded ?

It is still in my inbox.
# received letters/day >> # answered letters/day

A careful answer requires inspection of the development of
the code involved. Let me give a rough answer from memory,
clarifying why mkswap contains severe restrictions.

Long ago:
Swap space started with a bit map of bad blocks. This is v0.
Later:
Swap space starts with a header that lists the bad blocks. This is v1.

V1 swap space was a disaster for several reasons.

The first problem is that nobody knows where the signature is,
because that is at the end of the page, and a "page" may be a
natural object for a kernel developer, it is not in user space.
Right now a large part of the source of mkswap consists of finding out
how large a page is, and in bad cases we can't, and need a user option.

The second problem is that old kernels will refuse the swapon
system call when the swapspace is too large (instead of only
using the part the kernel likes). That again means lots of
garbage code, trying to figure out what size swapspace the kernel
will accept.

The strange limitations documented in mkswap(8) are true limitations
for certain oldish kernels. If the assumption is that nobody uses
2.2 anymore then these can be removed. But lots of people still use 2.2.

I might send Alan a patch to remove this restriction in 2.2.

Alan: the bad fragment lives in swapfile.c and is

if (p->max >= SWP_OFFSET(SWP_ENTRY(0,~0UL)))
goto bad_swap;

If it is still there (I have somewhat poor net and source access
right now) it could be changed to something like

swaplimit = SWP_OFFSET(SWP_ENTRY(0,~0UL));
if (p->max >= swaplimit)
p->max = swaplimit-1;



Andries

Let me cc l-k.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/