Date: Fri, 28 Apr 1995 15:27:25 +1000 From: Bruce Evans <bde@zeta.org.au> To: current@FreeBSD.org, gene@starkhome.cs.sunysb.edu Subject: Re: Disk slicing problems Message-ID: <199504280527.PAA19697@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
> (1) Though I can mount, say /dev/wd0s4e, /dev/wd0s4f on
> /usr and /local, I am not yet able to use /dev/wd0s4a
> as / and /dev/wd0s4b as swap. Is this supported?
> Do I have to do something special in the kernel config,
> like change "root on wd0" to "root on wd0s4"?
If you only have one FreeBSD partition, then you can continue to use
wd0[a-h]. You can also continue to use these for the first of multiple
FreeBSD partitions. If you have more than one, or just want use explicit
slices, then you have to do something special:
For swapping, something like "swap on wd0s4" is required and is supposed
to work (it hasn't been tested much). A better solution is required.
Already the swap list has to have all devices that you might want to
swap on. Multiply this by up to 30 slices per device and the list is
much too long.
Booting from wd0s4 is not fully supported. The bootstrap passes the slice
number but autoconfig.c neglects to use it, so only booting from the
first slice works. The root device in normally autoconfig'ed to the root
device, so it is hard to use wd0s4 for root. My fix for this got mixed
up with correcting the floppy minor numbering and the time never seemed
right to commit it. I haven't been using it either.
> (2) After having gotten a kernel booted with disk slicing
> turned on, I find that I am unable to modify the MBR,
> and I am also unable to perform certain modifications
> to the disklabel. My understanding was that I am
> supposed to be able to use /dev/rwd0 as "the whole disk",
> and thus access and modify the MBR that way. However,
> when I try, say, "fdisk -u /dev/rwd0" it fails to write
> the MBR, complaining that the operation is not supported.
Here it has no problem writing the MBR, but it complains about not being
able to write the possibly-modified label back to rwd0. There is no
label on the disk for rwd0 and changing the dummy in-core label doesn't
make much sense. The ioctl actually returns ENODEV, and disklabel(8)
doesn't know what this means.
> Also, whereas under older kernels I was able to perform
> various kinds of "dangerous" modifications to the disklabel
> while the system is up, I can no longer do this.
You can probably still do this by running `open("/dev/rwd0", 0); sleep(~0u);'
> For example, I had my BSD slice starting at offset 1,
> with the a partition starting at offset 1008. I wanted
> to shrink the BSD slice so that it starts at offset 1008
> to coincide with the start of the a partition, but there
> seems to be no way to do this once the initial slice
> table and disklabel have been written. Any attempt to
Shrinking the slice in the MBR would work right provided no minors other
than rwd0 are open. You would get a message about the C partition being
too large and being shrunk when a minor is opened later (after rwd0 is
closed).
> change the disklabel in this way results in a complaint
> that the "change would shrink an open partition".
Well, it is open. setdisklabel() has always carefully checked for open
partitions, but previous drivers lied to it and said that no partitions
are open. There is obviously a problem handling the parition that you
unfortunately have to have open to do an ioctl() on it. Perhaps drivers
should pretend that the C partition is not open. However, it's not clear
that changing the size of the C partition or the slice size should be
allowed at all. These sizes are normally inherited from the DOSpartition
table and are restricted by it. However^2, reducing them was supposed to
work. We currently have better utilities for managing labels than slices.
> In summary, I would like to be able to make these "dangerous"
> modifications, as long as I am willing to accept whatever
> consequences accrue from making them on the fly. Typically,
> what I would want to do is rewrite the MBR and disklabel,
> then reboot immediately if I moved the root area or something.
> The current system of interlocks seems to effectively
> prevent me from doing anything except reloading my entire
> disk from scratch.
The correct technique is:
a) Close all minors on the disk. If the disk has your root partition then
you will have to boot from another disk or possibly another slice on the
same disk if you only want to do dangerous mods to the first slice. If
the disk has swap activated on it, then reboot and don't activate swap.
(BTW, I fixed(?) the disk close routines to not keep open swap partitions
(activated or not). This makes it possible to close all minors on the disk
provided all swap partitions on the disk are inactive. However, the vm
system apparently caches the swap sizes (it has to for pstat -s to report
inactive swap), so there would be big problems if you shrunk or moved the
swap partition and then used it.)
b) Change the MBR.
c) Change all labels. Be careful to delete or fix all old labels that have
reappeared or been invalidated by step (b).
The interlocking is currently not complete, so you can do step (b) without
affecting anything if some minor is open. This will be fixed using the
new unfinished DIOCSYNCSLICES ioctl() in fdisk. The ioctl() may fail if
some minors are open, but fdisk will be able to tell.
> (3) I do not understand what the current wisdom is as far as
> laying out BSD partitions with respect to cylinder boundaries.
> With the advent of disk slicing, the disklabel now seems
> to be "relativized" to the beginning of the slice, with
> the effect that it gets very confused about what starts
> at a cylinder boundary and what does not. I am not
If cylinder boundaries matter, then all slices should be started on them.
> particularly thrilled about this relativization; I would
Neither am I. I'll think about changing this. There is probably more
slice code to delete than old code to fix.
Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199504280527.PAA19697>