Date: Thu, 25 Sep 2008 21:57:08 +0000 From: "Poul-Henning Kamp" <phk@phk.freebsd.dk> To: Marcel Moolenaar <xcllnt@mac.com> Cc: FreeBSD Arch <arch@freebsd.org> Subject: Re: RFC: making gpart default Message-ID: <11708.1222379828@critter.freebsd.dk> In-Reply-To: Your message of "Thu, 25 Sep 2008 14:24:49 MST." <901FB1DE-BA4C-405C-8F8E-AA8CCC6A89FA@mac.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <901FB1DE-BA4C-405C-8F8E-AA8CCC6A89FA@mac.com>, Marcel Moolenaar wri tes: >Granted, supporting all the details of a particular >scheme may not be easy or even possible. That's my worry about the unified UI, I keep thinking of the old usenet joke about the HP Cafeteria. >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 :-/ >That's why I believe we need to attach real meaning >to the partition type. We should disallow a newfs_ufs >on a partition that is not of type freebsd-ufs. [...] Ouch. That is a level of policy that I would not want to enforce on users. This should probably be pointed out for arch@'s careful consideration: we are potentially talking about quite a lot of "it used to work, now it complains" email. >> 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. >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 ? 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 ? What about DVD/ISO images which don't have parititioning, with the exception of Sparc boot-media ? 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. It might make people thing twice, but likely only about what the point is supposed to be and why it has to be so difficult. I would strongly advice going for an inband scheme instead, we have that in g_label already. >>> 6. Not all "disk" devices have a geometry. Especially md(4) >>> devices and USB mass storage devices. This is a problem >>> for newfs_msdos. With gpart, there's always a geometry [...] >> >> I will argue this is wrong. > >It's not wrong. It's a consequence. As long as there are >partitioning schemes and file systems that use sectors, >track and/or cyclinders we need to provide it. It's not a matter of providing or not, it's a matter of constructing or not. md(4) has no geometry, and you don't know what the user is going to use the filesystem for. If you construct a synthetic default geometry, the user is not made aware that he needs to *think* about the correct geometry. >> I would be better to fix umass/cam/da (cross out your own code) >> to get the correct geometry from the usb-sticks. > >I totally agree. Then don't provide a hack to hide the hurt, let the hurt hit where it belongs. >> 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 :-) >> I think you should have talked a bit about naming of the >> partitions ? > >Good point. >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 ? (I would suggest gpart always show the /dev names) Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?11708.1222379828>