Let me split my reply into two, this the uncontroversial one, then separately about swapon writing swap header. On Thu, 22 Jan 2009, Karel Zak wrote: > 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). Okay, thanks for the info. I'll probably just continue to leave that page alone in the kernel, for safety; but might change my mind. > > Anyway, those are the diversions I wanted to raise with you, but > > on to the mkswap patch in question > > .... > > 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. Thanks. > > > 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). Fine, thanks: it is a bugfix, but not one I've heard anyone crying out for. Hugh -- 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
