В UDF, в чем разница между идентификатором тома, идентификатором набора томов, идентификатором логического тома и идентификатором набора файлов?

3302
derobert

Я вижу, что 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 Spec 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.
  • Другие существуют только для того, чтобы тратить место на диске, не имея реального описания того, для чего они предназначены. Несмотря на это, я должен установить для них значения, которые не являются ни фиксированными, ни тривиальными. Возможно, я должен просто установить их на случайные (то есть, не фиксированные) строки из Шекспира (то есть, не тривиальные).

Или еще лучше: для чего нужны другие поля?

17
Используйте UUID, а не строки Шекспира. Daniel Beck 12 лет назад 1
@DanielBeck: Ну, есть примечание о поле VolumeSetIdentifier, в котором говорится, что первые 16 должны быть уникальными, а первые 8 из них являются метками времени ... Так что я предполагаю, что UUID не разрешен, но опять же ни Шекспир Однако я волнуюсь, что UUID могут считаться «тривиальными». :-P Если серьезно, я подозреваю, что набор громкости по назначению похож на набор громкости в ISO9660, т. Е. Что-то, что никто не использует, но комитет все равно добавил. derobert 12 лет назад 0

4 ответа на вопрос

2
Nikolai

These are bunch of not useful strings, except LVID.

Form mkudffs:

  • --lvid Specify the logical volume identifier. It sets given string to the following fields:
    • Logical Volume Identifier in the Logical Volume Descriptor (See Figure 15 in ECMA-167)
    • Logical Volume Identifier in the Implementation Use. (See 2.2.7.2 in UDF 2.01)
    • Logical Volume Identifier in the File Set Descriptor. (See Figure 9 in ECMA-167) File Set Descriptor. (See Figure 9 in [ECMA-167][5]).
      Logical Volume Identifier shown in windows as disk label.
  • --vid Specify the volume identifier. It sets givend string to the Volume Identifier field in the Primary Volume Descriptor. (See Figure 6 in ECMA-167). Maximum length 31 bytes. Default value "Linux UDF".
  • --vsid Specify the volume set identifier. It sets given string to the volume set identifier field in the Primary Volume Desriptor. (See Figure 6 in ECMA-167). Maximum length 127 bytes. Default value "Linux UDF".
    Volume Set Identifier can be edited by some Disk authoring programs like ImgBurn, MagicISO. It specify an identification of the volume set of which the volume is a member.
  • --fsid Specify the file set identifier. It sets File Set Identifier field in the File Set Descriptor. (See Figure 9 in ECMA-167). Maximum length 31 bytes. Default value "Linux UDF".
Да, я прочитал справочную страницу и эти разделы стандартов (в конце концов, я связался с ними в своем вопросе) ... Вопрос в том, что это за поля * для *, а не как их устанавливать. derobert 9 лет назад 0
1
András Korn

I think these are completely up to you; I'd say the fields are there to support enterprise processes. One use that comes readily to mind is to use the volume set identifier for stuff like "monthly full backup of FOO, 2015-12", and the volume identifier could then be something like "disk 1 of 42". Or maybe you'll actually have a physical identifier, e.g. a barcode, printed on the disk, and the volume identifier can hold that (so that you can identify the disk either by reading it in a drive or by pointing a barcode reader at it).

I imagine the file set identifier could be useful when you're putting a bunch of files in the filesystem that form some manner of logical unit (a "set"), but they don't intuitively form a "volume"; for example, "Mariah Carey .gifs 1994-1998" or "Bob's high school essays".

0
Elder Geek

Логически говоря, все эти поля существуют для того, чтобы содержать данные, в которых некоторые члены (или члены) комитета, которые разработали и / или изменили стандарт, увидели необходимость. Тот факт, что кто-то считает, что это пустая трата места на диске, не означает, что на момент согласования стандарта не было одного или нескольких мнений по этому вопросу. Фактически, некоторые члены или члены комитета считали их достаточно полезными для той или иной цели, и они попали в стандарт. Я говорю, что все, что явно не определено в стандарте, открыто для интерпретации и, следовательно, может использоваться либо для любых целей, которые вы пожелаете, либо безопасно игнорировать до тех пор, пока оно не будет явно определено стандартом. С точки зрения разработки программного обеспечения, 'mkudffs' не нужно определять, для чего вы должны использовать эти поля,

0
WGRM

Я думаю, что эти ценности ориентированы на другие спецификации, которые сами пытаются обобщить медиа-мн. В моем примере я буду ссылаться на Linux, но это не значит, что это не относится к Windows. Эти спецификации. там просто спрятаны

Запустите следующий cmd в Linux и посмотрите на вывод: 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, и я склонен полагать, что это ошибка реализации некоторого вида. Потому что я когда-то читал в этой сети, что это было реализовано позже, потому что чел. не удалось смонтировать UDF-носитель по UUID. Таким образом, это могло быть неправильное понимание данных полей свойств. Я не знаю, куда помещается текущий UUID, но blkid читает этот как UUID. Я не знаю, является ли это драйвером UDF или проблемой blkid. Может быть, кто-то пишет письмо с подсказкой соответствующему человеку / группе.

Похожие вопросы