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

我看到mkudffs有四个不同标识符的选项：逻辑卷（--lvid），卷（--vid），卷集（--vsid）和文件集标识符（--fsid）。但是，它没有给出任何含义的指导。

所以，我去了UDF规范。从ISO / IEC 13346 aka ECMA-167开始，我发现：

10.1.4卷标识符（BP 24）

该字段应指定体积的标识。

14.1.10逻辑卷标识符（BP 112）

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

14.1.12文件集标识符（BP 304）

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

好吧，这很有用。

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

我尝试了UDF 1.50规范，该规范在第4.1节中进一步告诉我，在显示这些值之前，必须应用使用第4.1.2.1节中描述的算法的特定于操作系统的转换。当然，§4.1之后的下一部分是§4.2，因此祝您好运。同样，“逻辑卷标识符”在自动存储塔中存在多种媒体时，在逻辑卷识别中也极为重要。该名称通常是显示给用户的名称。

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

因此，据我所知：

• 逻辑卷标识符是显示给用户的（可能只有自动存储塔）。因此，应将其设置为有意义的名称，例如光盘标题。我假设这是Windows，Mac OS或Nautilus会显示的光盘标题。
• 其他的存在只是为了浪费光盘上的空间，而没有对其用途的实际描述。尽管如此，我应该将它们设置为既不固定也不琐碎的值。可能的话，我应该将它们设置为来自莎士比亚的随机（即不固定）线（即不平凡）。

或者，更好的是：其他领域还做什么？

这些是一堆没有用的字符串，除了LVID。

表格mkudffs：

• --lvid指定逻辑卷标识符。它将给定的字符串设置到以下字段：
  • 逻辑卷描述符中的逻辑卷标识符（请参阅ECMA-167中的图15 ）
  • 实施用途中的逻辑卷标识符。（请参阅UDF 2.01中的 2.2.7.2 ）
  • 文件集描述符中的逻辑卷标识符。（请参阅ECMA-167中的图9 ）文件集描述符。（请参阅[ECMA-167] [5]中的图9）。
    逻辑卷标识符在窗口中显示为磁盘标签。
• --vid 指定卷标识符。它将给定的字符串设置为主卷描述符中的“卷标识符”字段。（请参阅ECMA-167中的图6 ）。最大长度为31个字节。默认值“ Linux UDF”。
• --vsid指定卷集标识符。它将给定的字符串设置为主卷Desriptor中的卷集标识符字段。（请参阅ECMA-167中的图6 ）。最大长度为127个字节。默认值“ Linux UDF”。
  卷集标识符可以通过某些磁盘创作程序（如ImgBurn，MagicISO）进行编辑。它指定该卷所属的卷集的标识。
• --fsid指定文件集标识符。它在“文件集描述符”中设置“文件集标识符”字段。（请参阅ECMA-167中的图9 ）。最大长度为31个字节。默认值“ Linux UDF”。

我认为这些完全取决于您；我想说的是那里的领域来支持企业流程。容易想到的一种用途是将卷集标识符用于诸如“ FOO的每月完整备份，2015-12”之类的东西，然后该卷标识符可以类似于“ 42的磁盘1”。或者，也许实际上您会在磁盘上打印出一个物理标识符，例如条形码，并且卷标识符可以保存该标识符（以便您可以通过在驱动器中读取磁盘或将条形码阅读器指向磁盘来识别磁盘）。

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

从逻辑上讲，所有这些字段都存在以包含一些制定和/或修改该标准的委员会成员认为需要的数据。仅仅因为有人认为这浪费了磁盘空间，并不意味着在达成标准后就没有一个或多个意见。实际上，委员会的一些成员认为它们对于一个目的或另一个目的足够有用，以至于使他们成为了标准。我说任何未在标准中明确定义的内容都可以解释，因此可以将其用于您想要的任何目的，也可以安全地忽略该对象，直到由该标准明确定义为止。从软件创作的角度来看，“ mkudffs”不需要定义您应将这些字段用于什么，

我认为这些价值观以其他规范为导向，他们自己试图对媒体mngt进行概括。在我的示例中，我将提及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属性，我倾向于相信，这是某种实现错误。因为我曾经在这个网络上阅读过，所以后来才实现，因为ppl。无法通过UUID挂载UDF介质。因此，这可能是对给定属性字段的误解。我不知道当前的UUID放在哪里，但是blkid将此读为UUID。我不知道这是UDF驱动程序还是blkid问题。也许有人写一封带有提示的邮件给相应的人/组。