Date: Fri, 25 Oct 2002 23:15:47 +0100 (BST) From: Mark Valentine <mark@thuvia.demon.co.uk> To: Julian Elischer <julian@elischer.org> Cc: Poul-Henning Kamp <phk@critter.freebsd.dk>, "M. Warner Losh" <imp@bsdimp.com>, freebsd-arch@freebsd.org Subject: Re: cvs commit: src/lib/libdisk Makefile chunk.c write_alpha_disk.c write_i386_disk.c write_pc98_disk.c Message-ID: <200210252215.g9PMFlBO083244@dotar.thuvia.org> In-Reply-To: <Pine.BSF.4.21.0210251415390.7147-100000@InterJet.elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> From: Julian Elischer <julian@elischer.org> > Date: Fri 25 Oct, 2002 > Subject: Re: cvs commit: src/lib/libdisk Makefile chunk.c write_alpha_disk.c write_i386_disk.c write_pc98_disk.c > In other words, you ignored the warnings for 5 years and instead of > explaining teh problem to people that could think about what is needed, > you just covered it up using somethign we've been telling you not to do. I guess I didn't expect the "compatibility slice" to ever go away... > Ok, so, better late than never.. exactly WHY do you need to use > ad0a (or whatever)? I can't think of any reasons for keeping that > old compat stuff other than giving people more time to fix their > fstabs. Enlighten me.. > > There is currently a mechanism for making FreeBSD play ball better with > > the systems it shares a disk with. > > > > GEOM in its current state removes this mechanism, with no replacement. > > I fail to see how using ad0a makes it play better with other systems. Because DOS doesn't refer to its partition by its index in the MBR partition table, and apparently some tools therefore feel free to reorder the table on a whim. /dev/ad0a results in a method of locating the partition which is closer to the DOS algorithm, and therefore survives this. /dev/ad0s1a makes an incorrect assumption about the MBR partition table index being fixed, and therefore blows up. > > You're simply describing the obscure usage I mentioned earlier. Modulo > > the 8 partition limit, there's nothing here a single disklabel can't do; > > in fact that's all we have on most BSD platforms. > > in which case it's correct naming would be > ad0a ad0b ad0c ad0d etc. > and GEOM isn't going to change that. Apparently it is, even for DD mode. > > > if you don't know where your root is you are in trouble. > > > > I know where my root is - it's BSD partition 'a' on the MBR partition of > > type 0xa5. There is no guarantee as to which partition table entry might > > refer to that partition at any given time. That is not my choice, it's > > based on the assumptions made by DOS (which originally implemented the > > MBR partition table). > > If you are going to repartition your disk, then fix the fstab before you > reboot for goodness' sake! It's not so complicated! I'm not repartitioning in any way which should affect FreeBSD. It doesn't sound complicated in this scenario, but when you consider the partition table index embedded in backups and in scripts, it's another matter. > It still doesn't help you to have the shortcut if you decide > to reuse an earlier partition as extra BSD storage. I can choose betwen hardwiring partition table indexes or using a single disklabel (is it still possible to refer to the area outside the partition containing the BSD disklabel in disklabel entries?). But basically I just don't do this. Does GEOM improve anything here? > > All I need is a way to tell the system where it is so that my FreeBSD > > systems will continue to boot. > > it's on ad0s3a or where-ever you put it. ad0s3a is effectively a random place. > If you can't remember where you put it, well, that's not something we > are going to break a good abstraction for. I have to figure out where some tool left it, because FreeBSD with GEOM doesn't provide a way to specify it which matches how DOS sees it. An abstraction is lacking if it can't cope with the behaviour of the underlying system. > This is a case that will happen 4 times a year in the entire world > in my opinion. Once with you and 3 times with bruce because he will want > to prove it's a problem. Sure, it's only an occasional nuisance. However, it reflects a flaw in the system, and is not its only manifestation (see my point about scripts and backups). Cheers, Mark. -- Mark Valentine, Thuvia Labs <mark@thuvia.co.uk> <http://www.thuvia.co.uk>; "Tigers will do ANYTHING for a tuna fish sandwich." Mark Valentine uses "We're kind of stupid that way." *munch* *munch* and endorses FreeBSD -- <http://www.calvinandhobbes.com>; <http://www.freebsd.org>; To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200210252215.g9PMFlBO083244>