> 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.
On Mon, Aug 18, 2003 at 08:39:28PM +0200, [email protected] wrote:
> 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.
Thanks for the clarification.
> 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 would strongly prefer that such documentation of older restrictions be
moved to the NOTES section of mkswap(8). The set of users who :
o are using util-linux 2.12+
o are using pre-2.4 kernels
o will read the mkswap(8) man page
o will not read such a NOTES section
seems relatively small to me when compared to the number of users
confused by the text (including the admin who originally brought this
up, was under the impression the limit still applied generally due to
the man page, and has also been told so by Red Hat support).
regards,
john
--
Khendon's Law:
If the same point is made twice by the same person, the thread is over.