On Mon, 26 Jan 2009, Olaf Hering wrote: > On Fri, Jan 23, Hugh Dickins wrote: > > > 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). > > The swap signature is not just a random string at a random place, mkswap > does also check if the partition or filesize matches with the metadata. > So its unlikely that an innocent partition or file gets corrupted by > mkswap, but it can probably still happen. > I agree that mkswap (or whatever does the validation) should be more > careful and rewrite more parts of the metadata for the current pagesize. > > If there is a bug in the current 11.1 or upstream implementation, > please help to get it fixed. In my view, it's a bug that swapon is rewriting the swap header at all: that is the job of mkswap; and if you want the swap header rewritten, you should be calling mkswap, not having it called behind your back. But that is not your view, I think: so I propose the compromise that we add an option to swapon to allow this, and you use that option in your startup scripts. I got bitten by this, not through the badpage list, but because I'd set up a specific swap size for testing (via mkswap device size), and was surprised to find that replaced by size of swap partition - didn't realize 11.1 on the G5 was using pagesize 64kB, and rewriting swapheader whenever I switched between my kernel and 11.1's. It is not common practice to change the default behaviour of a standard utility in the way that you have; and both our posititions can easily be accommodated by the addition of an option to enable the new feature that you want. 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
