Date: Thu, 25 Sep 2008 17:26:54 -0700 From: Marcel Moolenaar <xcllnt@mac.com> To: Poul-Henning Kamp <phk@phk.freebsd.dk> Cc: FreeBSD Arch <arch@freebsd.org> Subject: Re: RFC: making gpart default Message-ID: <834AD44B-2372-41D2-A952-85095569BB48@mac.com> In-Reply-To: <11708.1222379828@critter.freebsd.dk> References: <11708.1222379828@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sep 25, 2008, at 2:57 PM, Poul-Henning Kamp wrote: >> >> Trying to use the native scheme is generally good. >> But I do expect that FreeBSD on platform X knows >> or recognizes a disk created on or used by FreeBSD >> on platform Y. > > Until we have an endianes aware UFS that's only > half the solution however :-/ File system bugs are outside the scope of gpart. It's already a much better situation if we can see the partitions on a "foreign" disk, even if we can't interpret the data in it. >>> Overall this is a fine point, but I'd hate to make it easier to >>> trash filesystems. >> >> I agree. Enforcing that partition types match the >> content (within reason) is a good start. > > I don't see it that way, I see it as increasing the risk > when people move partitions around with g_mirror or dd. There's no risk that wasn't there already. In fact, certain things won't work, which means risk is reduced. >> Keeping consistency can only be the responsibility >> of the user/admin. > > So we ask the users to keep it consistent so it can > protect the users by being consistent ? No, we don't ask the user anything. We just reward the user with certain benefits when he/she is keeping things real. Changing the partition type to match the content is for the benefit of the admin as well. It's a win-win. > I'm not quite sure I see the benefit, but I see lots of trouble: > > Does that mean I can't newfs /dev/da1 without partitioning ? When there's no partitioning scheme, then gpart is not involved and we can obvouisly not check partition types. > What about DVD/ISO images which don't have parititioning, > with the exception of Sparc boot-media ? See above. > In my view, enforcing out of band labels on partitions amounts to > nothing but pointlessly putting signs with "coffee-machine" and > "stupid ISO9000 signage guy" on stuff. While I find some of the labels redundant, it would be a mistake to think that there isn't someone out there who depends on them. > I would strongly advice going for an inband scheme instead, > we have that in g_label already. It would be nice if g_label would use the labels that people put in the partition table for entries. > If you construct a synthetic default geometry, the user is not made > aware that he needs to *think* about the correct geometry. We obviously have 2 viewpoints here: On forces the user to worry about geometry, even if there's no need for it. The other avoids the user from having to think about geometry, even if the user should. I'd rather treat our users as knowledgeable and not as being stupid. I prefer to assume that the user knows when to worry about geometry so that we can make it easy in case it doesn't matter. It's all about the ability to specify a geometry when you create the partitioning scheme. This can not be done with gpart at this time, though. >>> This is going to break more scripts than you think. >> >> Likely. > > I do find your attitude to compatibility refreshing, but will take > care to be at a safe distance when the consequence strikes :-) There's limited compatibility in replacing arcane tools each with their own UI with a unified tool that's based on a totally different paradigm. Striving for tool-compatibility would not be successful by definition. It's much easier to rewrite bsdlabel and fdisk to use the gpart ctlreq I/F directly... >> On my server (FreeBSD 7.x) "gpart show" gives: >> >> ns1% gpart show >> => 63 80293185 ad0 MBR (41.1GB) >> 63 80292807 1 freebsd [active] (41.1GB) >> 80292870 378 - free - (193.5KB) >> >> => 0 80292807 ad0s1 BSD (41.1GB) >> 0 2097152 1 freebsd-ufs (1073.7MB) >> 2097152 16777216 2 freebsd-swap (8.6GB) >> 18874368 16777216 4 freebsd-ufs (8.6GB) >> 35651584 44641223 5 freebsd-ufs (22.9GB) > > My question was really if these partitions have > the same name in /dev/ as today, ad0s1[a-d] presumably ? Yes. The device naming has not changed. -- Marcel Moolenaar xcllnt@mac.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?834AD44B-2372-41D2-A952-85095569BB48>