NetBSD Problem Report #57348

From www@netbsd.org  Thu Apr 13 08:56:47 2023
Return-Path: <www@netbsd.org>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits))
	(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
	by mollari.NetBSD.org (Postfix) with ESMTPS id 4EBF51A9239
	for <gnats-bugs@gnats.NetBSD.org>; Thu, 13 Apr 2023 08:56:47 +0000 (UTC)
Message-Id: <20230413085646.418D61A923A@mollari.NetBSD.org>
Date: Thu, 13 Apr 2023 08:56:46 +0000 (UTC)
From: campbell+netbsd@mumble.net
Reply-To: campbell+netbsd@mumble.net
To: gnats-bugs@NetBSD.org
Subject: dk(4) wedges should always be referenceable by uuid
X-Send-Pr-Version: www-1.0

>Number:         57348
>Category:       kern
>Synopsis:       dk(4) wedges should always be referenceable by uuid
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu Apr 13 09:00:00 +0000 2023
>Last-Modified:  Thu Apr 13 10:00:01 +0000 2023
>Originator:     Taylor R Campbell
>Release:        current
>Organization:
The NetBSD Wedgeation
>Environment:
*sizzle*
>Description:
dk(4) wedges have two namespaces:

- autoconf device number, which is unreliable and may depend on stochastic scheduling reordering;
- name, which must be unique, and for partitioning schemes with both names and uuids is chosen to be name if unique or uuid on name collision.

This means that, even if partitions have unique uuids, they can't be both named and referred to in fstab(5) or similar with uuid.


>How-To-Repeat:
Insert two disks with the same name, like `netbsd-boot', one of which is an internal SSD and the other of which is an external USB flash drive, with an fstab(5) entry to mount it.  Watch their fstab(5) files confuse the partitions.
>Fix:
Create a third namespace by which wedges can be referenced by uuid.  Of course, this can have collisions too, but in practical terms collisions are less likely to happen and this allows us to put human-meaningful names on partitions without also breaking machine-readable references to them.

>Audit-Trail:
From: mlelstv@serpens.de (Michael van Elst)
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: kern/57348: dk(4) wedges should always be referenceable by uuid
Date: Thu, 13 Apr 2023 09:56:34 -0000 (UTC)

 campbell+netbsd@mumble.net writes:

 >- autoconf device number, which is unreliable and may depend on stochastic scheduling reordering;
 >- name, which must be unique, and for partitioning schemes with both names and uuids is chosen to be name if unique or uuid on name collision.

 "Partitioning schemes with names and uuids" means, the GPT reader does this.

 Wedge names always must be unique, otherwise the wedge cannot be created.

 >This means that, even if partitions have unique uuids, they can't be both named and referred to in fstab(5) or similar with uuid.

 Wedges only have one single name, they never had UUIDs.

 On GPT-based wedges, the GPT partition UUID is used as a default name.
 On other parititoning schemes, there is no UUID and often not even a name.

 UUIDs also do not solve the collision problem in case you copy disk images. This is also the reason that
 creates name collisions in the first place. If every partition name is copied as "boot", "system" or "data"
 it's not really a name.

 Other systems also add things like volume names or filesystem labels, which are part of the filesystem
 structure and not of the partitioning scheme. These would be more suitable as human identifiers, unfortunately
 FFS doesn't support such meta information (nor would we handle it).

 So the problem isn't that simple and having three namespaces might not be enough, which is the reason why there is
 still only a single name. Basically saying: that conflict might be better solved on a different level.


 Maybe adding a unique (time based?) serial number to a disklabel would be a good start. Then we talk about
 a unique wedge name, and a given wedge name and start to support that.

Home	PR Database Search