Date: Sun, 23 Oct 2005 10:49:00 -0700 From: Chris Pressey <cpressey@catseye.mine.nu> To: geom@freebsd.org Subject: fdisk(8) can't alter in-core geometry on unintialized disk anymore? Message-ID: <20051023104900.46836c55.cpressey@catseye.mine.nu>
next in thread | raw e-mail | index | archive | help
Hello, Unless I'm mistaken, it's no longer possible for fdisk(8) to change "our idea of what the BIOS thinks" for an uninitialized disk, under recent FreeBSD-CURRENT (as of 7 days ago - and probably for the last few months, by the look of the CVS logs.) The reasons for this seem to be twofold, and they seem to both be related to GEOM. On the "get the current geometry" side: - fdisk now asks GEOM when it wants to find out the geometry of a disk. - An uninitialized disk has no MBR, so no geom_mbr is created for it. - GEOM reports the geometry of a disk without a geom_mbr provider by passing the request through to the ATA layer(?) - The ATA layer reports only the geometry detected at boot(?) And on the "set a new geometry" side: - fdisk now asks GEOM when it wants to change the MBR and the geometry of a disk. - Because the uninitialized disk has no geom_mbr, this fails. - fdisk falls back to writing an updated MBR to the right place on the raw disk device, with a call to pwrite(2). - This, however, does not affect the in-core geometry. This can be evidenced by: - running fdisk -u adX - changing the geometry - telling fdisk to write out changes - running fdisk adX and observing that the geometry did not change. As for a possible solution: this is largely a shot in the dark since I don't know anything about GEOM, but it seems to me that it would be most appropriate for fdisk to trigger the creation of a geom_mbr provider on the disk when it doesn't have one yet. Since the geom_mbr presumably requires a valid MBR, this would have to happen after the raw pwrite() of the MBR to the disk. And after that, the GEOM verb to alter the MBR would have to be repeated, so that the in-core geometry gets updated. Does this analysis seem reasonable? At any rate, if someone could confirm that this really is a regression, and not just something that is happening on my system and/or some intentional new behaviour(?), that would be great. Thanks in advance, -Chris
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20051023104900.46836c55.cpressey>