在 UDF 中，卷标识符、卷集标识符、逻辑卷标识符和文件集标识符之间有什么区别？

Question

我看到mkudffs有四个不同标识符的选项：逻辑卷 ( --lvid)、卷 ( --vid)、卷集 ( --vsid) 和文件集标识符 ( --fsid)。但是，它没有提供这些含义的指导。

因此，我查阅了 UDF 规范。从 ISO/IEC 13346 开始，又称ECMA-167， 我发现：

10.1.4 卷标识符 (BP 24)

该字段应指定卷的标识。

14.1.10 逻辑卷标识符 (BP 112)

该字段应指定记录文件集的逻辑卷的标识。

14.1.12 文件集标识符 (BP 304)

该字段应指定该文件集描述符所描述的文件集的标识。

嗯，这很有用。

因此，我尝试了OSTA UDF 规范 1.02，因为这是我尝试生成的 UDF 版本。它没有多大帮助（尽管它提醒我不要使用“固定或琐碎的值”）。

我尝试过UDF 1.50 规范这进一步告诉我——在 §4.1 中——在显示这些值之前，必须应用 §4.1.2.1 中描述的使用算法的特定于操作系统的转换。当然，§4.1 之后的下一节是 §4.2，所以祝你好运。此外，LogicalVolumeIdentifier“在点唱机内存在多个媒体时，在逻辑卷识别中极其重要。名称通常是显示给用户的内容。”

因此，我尝试UDF 2.01 规范，现在我知道了，至少他们现在已经意识到是 4。2.2.1，确实存在，但没有帮助（它处理诸如字符集之类的东西）。

因此，据我所知：

• 逻辑卷标识符是向用户显示的内容（可能仅由点唱机显示）。因此，应将其设置为有意义的内容，例如光盘标题。我假设这是 Windows、Mac OS 或 Nautilus 将显示的光盘标题。
• 其他的只是为了浪费磁盘空间，没有实际的描述它们的用途。尽管如此，我应该将它们设置为既不固定也不琐碎的值。可能，我应该将它们设置为莎士比亚的随机（即非固定）台词（即非琐碎）。

或者更好的是：其他字段是做什么用的？

Answer 1

这些都是无用的字符串，除了左心室收缩末期。

形成 mkudffs：

• --lvid指定逻辑卷标识符。它将给定的字符串设置为以下字段：
  • 逻辑卷描述符中的逻辑卷标识符（参见ECMA-167）
  • 实现中使用的逻辑卷标识符。（请参见第 2.2.7.2 节）UDF 2.01）
  • 文件集描述符中的逻辑卷标识符。（参见ECMA-167）文件集描述符。（参见[ECMA-167][5]中的图9）。
    逻辑卷标识符在窗口中显示为磁盘标签。
• --视频 指定卷标识符。它将给定的字符串设置为主卷描述符中的卷标识符字段。（参见图 6ECMA-167）。最大长度31字节。默认值为“Linux UDF”。
• --vsid指定卷集标识符。它将给定的字符串设置为主卷描述符中的卷集标识符字段。（参见ECMA-167）。最大长度127字节。默认值为“Linux UDF”。
  卷集标识符可以由一些磁盘创作程序（如 ImgBurn、MagicISO）编辑。它指定卷所属的卷集的标识。
• --fsid指定文件集标识符。它设置文件集描述符中的文件集标识符字段。（参见ECMA-167）。最大长度31字节。默认值为“Linux UDF”。

Answer 2

我认为这些完全取决于您；我认为这些字段是为了支持企业流程而存在的。一个很容易想到的用途是使用卷集标识符来表示诸如“FOO，2015-12 的每月完整备份”之类的内容，然后卷标识符可以是“磁盘 1/42”之类的内容。或者也许您实际上会有一个物理标识符，例如打印在磁盘上的条形码，卷标识符可以保存它（这样您就可以通过在驱动器中读取它或通过将条形码读取器指向它来识别磁盘）。

我认为，当你将一堆文件放入文件系统中形成某种逻辑单元（“集合”）时，文件集标识符可能会很有用，但它们直观地形成“卷”；例如，“Mariah Carey .gifs 1994-1998”或“Bob 的高中论文”。

Answer 3

从逻辑上讲，这些字段都存在，以包含制定和/或修改标准的委员会成员认为需要的数据。仅仅因为有人认为这是在浪费磁盘空间，并不意味着在商定标准时没有对此事发表一种或多种意见。事实上，委员会的一些成员认为它们对于某个目的非常有用，因此它们被纳入了标准。我认为标准中未明确定义的任何内容都是开放的，因此可以用于任何您想要的目的，也可以安全地忽略，直到标准明确定义它为止。从软件创作的角度来看，“mkudffs”不需要定义您应该使用这些字段的用途，只需提供一种机制，允许您根据需要使用（或根据观点滥用）它们，从而符合标准。

Answer 4

我认为这些价值观面向其他规范，这些规范本身试图概括媒体管理。在我的例子中，我将参考 Linux，但这并不意味着它不适用于 Windows。那些规范只是隐藏在那里。

在 Linux 上运行以下 cmd 并查看输出：blkid

/dev/x：LABEL="Windows" UUID="？" TYPE="ntfs" PARTLABEL="基本数据分区" PARTUUID="？"

/dev/y：LABEL="Linux" UUID="？" TYPE="ext4" PARTLABEL="存储" PARTUUID="？"

如您所见，每个都有 2 个描述字段：

• 分割
• 该分区上的文件系统

在这两种情况下，前者是人类可读的描述，后者是机器描述。就像在域名系统 (DNS) 中一样，因为机器描述 - UUID - 需要是唯一的。所以我们可以讨论分区的 nx 2 x 2 个数据字段。但是，由于光学介质没有分区，原始介质本身算作分区。这意味着始终有 2 x 2 = 4 个属性。让我们尝试将 UDF 属性放入上面的示例中：

/dev/x：LABEL="LVID" UUID="VID" TYPE="UDF" PARTLABEL="VSID" PARTUUID="FSID"

我搜索了几个小时并阅读了许多文章，但无法验证这一点。所以这只是一个假设。但对于 LVID，它是通过术语定义和试验来保证的。Linux 和 Windows（后者带有 WinCDemu）使用此属性作为分区的标签。对于光学介质而言，它就是介质本身。

它确实非常合适，但提出了一个问题。有一个额外的 UUID 属性，我倾向于相信，这是某种实现错误。因为我曾经在这个网络上读到过，这是后来实现的，因为人们无法通过 UUID 安装 UDF 媒体。所以这可能是对给定属性字段的误解。我不知道当前的 UUID 放在哪里，但 blkid 将这个读为 UUID。我不知道这是 UDF 驱动程序还是 blkid 问题。也许有人给相应的人/组写了一封带有提示的邮件。