Hi Hugh,
On Thu, Jan 22, 2009 at 04:46:57PM +0000, Hugh Dickins wrote:
> 1. It looked to me as if mkswap and kernel (sys_swapon) disagree by 1
> on what goes in the last_page field of the swap header - mkswap thinks
> it's what I'd indeed call "last page", whereas kernel thinks it's a
> total number of pages, so never actually uses that page. The error
> is the safe way round, it's not a big deal, and there are clustering
> reasons why swap allocation would often tend not to use it anyway:
> I probably don't dare change the kernel for it now. But mention
> it to you in case it's something you've noticed or can confirm; or
> in case it comes from some relatively recent change in mkswap.c,
> which we could then safely reverse - do you see any change to what
> goes into last_page in recent mkswap history? Or am I just confused
> and off-by-one myself?
It seems that everything around last_page is pretty old:
$ git blame -L 688,+1 disk-utils/mkswap.c
5c36a0eb (Karel Zak 2006-12-07 00:25:37 +0100 688) p->last_page = PAGES-1;
$ git log 5c36a0eb
commit 5c36a0eb7cdb0360f9afd5d747c321f423b35984
Author: Karel Zak <kzak@xxxxxxxxxx>
Date: Thu Dec 7 00:25:37 2006 +0100
Imported from util-linux-2.9i tarball.
I guess v2.9 (1999) is the first version with SWAPSPACE2 (v2).
> 2. I've been disturbed to find the openSUSE 11.1 PowerPC swapon doing
> mkswap in some circumstances (when I specify device rather than "-a"?
> I'm not sure, I've not pinned it down yet). I can understand why
> they want that (PowerPC now supporting 4k and 64k and perhaps larger
> page sizes: the current swap_header is badly designed for that), but
> I do not like swapon modifying the swap header in such a way. Okay,
> I'm peculiar in setting up my swap size smaller then its partition,
> for particular testing reasons; but I do think swapon should leave
> it that way. A quick look at your -rc2 source suggests that change
I have a bad news for you. The -rc2 release is a stable tree. The
SUSE patch (with some improvements) is already in the devel (master)
branch. Please, see:
git://git.kernel.org/pub/scm/utils/util-linux-ng/util-linux-ng.git
we had a discussion about it, see:
http://article.gmane.org/gmane.linux.utilities.util-linux-ng/1817
Frankly speaking, I'm not proud of such swapon behaviour. Maybe we
can add to swapon a command line and fstab option to explicitly
disable such functionally.
The code has not been released yet. And I plan to work on
mkswap/swapon in next days. So suggestions/patches are welcomed.
(SUSE guys added to CC: if you want to talk about it with them.)
> is nothing to do with you, I guess it comes from a SUSE patch but
> I've not looked at their src.rpm yet. Though your swapon may mkswap
> for suspend reasons: hmm, wouldn't it do very much better just to
This patch was in Fedora, Debian, ..., for years before merge into
upstream. We have never seen any negative feedback.
> rewrite the swap signature, than exec mkswap - maybe nobody ever
Good idea. But we have to be sure that S1SUSPEND, S2SUSPEND,
... does not modify any other part of swap header.
> Anyway, those are the diversions I wanted to raise with you, but
> on to the mkswap patch in question. My kernel sys_swapon fix
> originally came from source inspection: when I went to test it,
> I had difficulty finding a filesystem which would allow a file
> that big - surprised to find ext4 did not, but xfs did allow it.
> Had to hack around mkswap's and kernel's tests for holes, since
> I certainly don't have disks that big. Managed in the end, but
I usually use device-mapper with COW snapshot to create a huge block
device (filesystem). Try:
http://people.redhat.com/kzak/scripts/sparse_create
> had to fix mkswap too: its unsigned long pagecounts are not quite
> big enough (when userspace is 32-bit) to handle the swap maxima.
> Easiest fix was to change several to unsigned long long (or that's
> what I'd do in the kernel: please keep in mind that it's years
> since I've done much userspace programming, and I've little
> grasp of its portability issues).
No problem, I'll review the patch later.
> If you consider support for such enormous swap areas something
> of a low priority, and prefer v2.14.2 without this, I'll find
> it very hard to argue against you!
The v2.14.2 is a stable maintenance release -- it means real bug fixes
or man pages updates. I think your patch can go to v2.15 (the current
master branch).
Karel
--
Karel Zak <kzak@xxxxxxxxxx>
--
To unsubscribe from this list: send the line "unsubscribe util-linux-ng" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
