RFC: making gpart default

[Poul-Henning Kamp]

In message <901FB1DE-BA4C-405C-8F8E-AA8CCC6A89FA at 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 at 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.