On Thu, 22 Jan 2009, Karel Zak wrote: > On Thu, Jan 22, 2009 at 04:46:57PM +0000, Hugh Dickins wrote: > > > 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. Bad news indeed. Any plans for mount to do a mkfs ;-? > 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 Thanks a lot for the pointers. And that explains a lot: I hadn't noticed that openSUSE 11.1 on ppc64 is actually using 64kB pages. (I'd have thought that a mistake for most installations, but since I had not yet noticed, I guess it can't be too glaring a mistake; and my opinion on that decision has no relevance here anyway.) Most of my time is spent with own-built kernels using 4kB pages. So each time I switch from my kernel to the original 11.1 one, or back, swapon will be rewriting the swap headers for me. Hmmm. It's not as gross as I'd first thought, only doing it on that switch; when I wrote, I hadn't pinned down just what led it to rewrite them. But I still feel strongly that it's NOT what swapon should be doing, certainly not by default, certainly not on all architectures. > > 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. You're right not to be proud of that behaviour; though swapon does indeed need to do something to help out with this situation. Of course the right solution was, when the first non-4096 paged architecture came along, to scrap that PAGE_SIZE in swap header definition, replace it by 4096, and modify kernel's sys_swapon to accommodate that factor (or perhaps SWAP-SPACE2 was already misdefined from the very start). Failing that, some such change should have been made when ia64 got into the business of multiple page sizes - I wonder how it has been coping with this situation? By using mkswap I imagine, that's the next best right thing. But trying to adjust the swap header now, too late, would not reduce anybody's workload, would only add to the confusion. My own preference would have been for swapon to detect the mismatch of page size, print an error, and exit with a specific error status code, which an invoking script could recognize and use to invoke mkswap if it wished. But that's a personal preference, and I don't think I have strong enough reason to turn everything around in that direction. What I most strongly object to is this behaviour happening by default: pity those who by mistake point swapon at the wrong partition, and it just happens to have what looks like a swapspace signature at one of the offsets (not a very great likelihood, I admit). Please, can we make it subject to a new option, -f perhaps? Then SuSE can add that option in their ppc64 scripts, and I can edit it out again, and nobody gets caught out by their swapon going off doing its own unexpected mkswap. By the way, that #define MAX_PAGESIZE (64 * 1024): there's people now using pagesize 256kB on ppc64, don't know if you want to cater for them too (maybe they're not using swap, or not switching). > > 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.) Thanks; and I've added Michael. > > > 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. And I never use suspend to disk, so I'd not noticed. As I said, for all I know, nobody in the world ever uses that badpage list in the swap header. If there is a tool to maintain it, I don't know what that tool is. But you can use a variety of tools to patch it, and maybe some people are: it's been in the definition for years, and the kernel is coded to skip those bad pages. So to my mind it's entirely wrong for the swapon utility to be rewriting that header, clearing the badpage list and adjusting the limits of the swap area, without even an option giving it permission to do so. > > > 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. Good point. I checked the various sources earlier today, though I didn't find an S2SUSPEND. They all modify some other part of the swap header, but not such that you need worry about it. S1SUSPEND and ULSUSPEND both modify the end of the badpage list, just before the signature: I really ought to lower MAX_SWAP_BADPAGES to reflect that. TuxOnIce modifies the start of the swap header (in the bootbits area). But neither area would need restoring when just rewriting the signature: a simple write of the signature would be much better than mkswap. 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
