On Sat, 24 Jan 2009, Karel Zak wrote: > On Fri, Jan 23, 2009 at 10:53:42PM +0000, Hugh Dickins wrote: [re: swapon running mkswap when pagesize doesn't match swapheader pagesize] > > Please, can we make it subject to a new option, -f perhaps? > > Yes, we can. That sounds better than exec mkswap by default. Thanks, Karel, that will pacify me! > > > 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). > > hmm.. is it supported by upstream kernel? No, not yet. Nor yet in the ppc dev tree, I think, but I'd expect it to find its way in over coming weeks/months. If you do include 256kB in the heuristic, then I doubt swap_get_pagesize() should be allocating a MAX_PAGESIZE buffer that big (when we likely don't have any swap yet): should be seeking and reading (or preading). But also think it should only be doing this when usual pagesize attempt failed. I was sceptical about the 265kB pagesize, Yuri justifies it here: http://lkml.org/lkml/2008/12/23/80 (Yuri, perhaps you have no interest whatever in swap, and would prefer to build your kernels with CONFIG_SWAP off? If that happens to be the case, then the best answer to our shmem overflow issue is for me to accelerate adding the #ifdef CONFIG_SWAPs which will magic away that limit, together with all tmpfs's then unnecessary swap overhead.) > > > 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. > > sounds good. > > BTW, there are many requests to zap bootbits area by mkswap (by > default when there is not a disklabel) to remove a superblock of the > original filesystem. Now we have very often valid swap area on a > valid filesystem... (Sometimes it's pretty dangerous, for example > some (idiotic) LiveCDs automatically call swapon when found a valid > swap header on disk.) I remember being caught by that kind of issue in the past (though not in such dangerous ways), and understand the desire for such zapping. But it's not something I have sufficient experience to advise on: I've always assumed there are strong legacy reasons why we cannot safely zap that area (and was surprised to see TuxOnIce doing so), and I hope someone with good legacy experience in Red Hat or SuSE can advise you. Do we have an example of a filesystem which zaps that area in its mkfs? 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
