[prev in list] [next in list] [prev in thread] [next in thread] 

List:       util-linux-ng
Subject:    Re: swapon using mkswap [changed subject]
From:       Matthias Koenig <mkoenig () suse ! de>
Date:       2009-01-27 10:57:13
Message-ID: n7xljsxt3sm.fsf () sor ! suse ! de
[Download RAW message or body]

Karel Zak <kzak@redhat.com> writes:

> On Mon, Jan 26, 2009 at 08:43:20AM +0100, 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.
>
>  what about to add "-r" (or so..) swapon option to enable automatic
>  swap area reinitialization after pagesize change? It means disable
>  the feature by default.

I have no objections making this feature configurable by an option.  But
shouldn't the default behaviour match the common use case (if such thing
exists)? Normally you want things to just work and do the 
right thing[tm]. And if you have a valid signature which just does not
match the current parameters you want this to be fixed (I assume ;-).
Anyway, if you have to enable this feature by an option, then every
invocation of swapon in the installer and the boot scripts must be
tracked down and changed there, it's not that that's not possible, it's
just more work. (Yes, I'm lazy ;-)

So, I would vote for keeping the default behaviour as it is now,
and adding an option to disable the feature.

Matthias
--
To unsubscribe from this list: send the line "unsubscribe util-linux-ng" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
[prev in list] [next in list] [prev in thread] [next in thread]