Subject: Swap beginning with cylinder 0
To: None <tech-kern@NetBSD.ORG>
From: der Mouse <mouse@Collatz.McRCIM.McGill.EDU>
List: tech-kern
Date: 05/22/1996 14:14:39
On the port-sun3 list, there's been a conversation...
>>>> Ah, so that's why I never could get my system to work with the
>>>> swap at the beginning of the disk!
>>> No, swap at the "beginning of the disk" will usually cause the disk
>>> label to be overwritten [...]
>> That's what I thought too, when I first heard of this problem. But
>> if you go look at swfree(), in vm/vm_swap.c, you'll see that it
>> [...] makes sure that it doesn't "use the first cluster of the
>> device in case it starts with a label or boot block".
> Just another data point: I've read that code too and thought it
> looked right, but have had problems with i386 machines which swap on
> the first cylinder of the boot disk (both wd and sd based ones)
> losing their boot blocks. The problems invariably went away if the
> swap partition was shrunk so that it started from the second cylinder
> on the disk instead. Never had a chance to try and actually nail the
> bug though.
I went and looked at the code. It does avoid the first cluster...but
this may not be enough.
The trouble is, it skips the first ctod(CLSIZE) entries in swapmap, and
how much that is varies. On the sun3 port, it seems to be 8K, which
happens to match the size of the reserved-for-boot area. On the sparc
port, it can be 4K or 8K...and if it's 4K, it'll destroy the second
half of the reserved area.
Other ports should probably look at what ctod(CLSIZE) comes out to and
compare it against how much space needs to be exempted from scribbling
at the beginning of the disk...and the sparc port may want to fix this.
There should be some machine-dependent value communicated somehow to
swfree() telling it how much space to skip, it seems to me.
I also intend to experiment, writing a distinctive pattern throughout
the swap area, rebooting, pushing the machine into swapping, and seeing
where the pattern remains un-swapped-over. For all swfree() looks
right, it may still be broken somehow...
der Mouse
mouse@collatz.mcrcim.mcgill.edu