I see that mkudffs has options for four different identifiers: the logical volume (--lvid), the volume (--vid), the volume set (--vsid), and the file set identifier (--fsid). It, however, gives no guidance to what those mean.

So, I went to the UDF specs. Starting with ISO/IEC 13346 aka ECMA-167, I find that:

10.1.4 Volume Identifier (BP 24)

This field shall specify an identification of the volume.

14.1.10 Logical Volume Identifier (BP 112)

This field shall specify an identification of the logical volume on which the file set is recorded.

14.1.12 File Set Identifier (BP 304)

This field shall specify an identification of the file set described by this File Set Descriptor.

Well, that was useful.

So, I tried the OSTA UDF Spec 1.02, as that is the UDF version I'm trying to generate. It didn't help much (though did caution me against "fixed or trivial values").

I tried the UDF 1.50 specification which further tells me me—in §4.1—that before displaying those values, that an OS-specific transform using algorithms described in § must be applied. Of course, the next section after §4.1 is §4.2, so good luck on that. Also, the LogicalVolumeIdentifier is "extremely important in logical volume identification when multiple media are present within a jukebox. The name is typically what is displayed to the user."

So, I try the UDF 2.01 specification, and now I know that By now at least they've realized it's, which does exist, but doesn't help (it deals with stuff like character sets).

So, so far as I can tell:

  • The Logical Volume Identifier is what is displayed to the user (possibly only by jukeboxes). So it should be set to something meaningful, e.g., the disc title. I assume this is the disc title that Windows, Mac OS, or Nautilus would display.
  • The others exist only to waste space on the disc, having no actual description of what they're for. Despite that, I should set them to values which are neither fixed nor trivial. Possibly, I should just set them to random (i.e., not fixed) lines from Shakespeare (i.e., not trivial).

Or, better yet: what are the other fields for?

  • 1
    Use UUIDs, not Shakespeare lines.
    – Daniel Beck
    Dec 11, 2011 at 10:13
  • @DanielBeck: Well, there is a note about the VolumeSetIdentifier field, which says the first 16 should be unique, the first 8 of those being a timestamp... So I guess for that one, UUID isn't allowed, but then again neither is Shakespeare. I do worry, though, that UUIDs may be considered "trivial". :-P On a serious note, I suspect the volume set stuff is similar in purpose to the volume set stuff in ISO9660, IOW, something no one uses, but the committee added anyway.
    – derobert
    Dec 11, 2011 at 10:42

4 Answers 4


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 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".
  • Yes, I've read the man page and those sections of the standards (after all, I linked to them in my question)... The question is what are those fields for, not how to set them.
    – derobert
    Apr 15, 2015 at 6:50

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".


Logically speaking those fields all exist to contain data which some member (or members) of the committee who developed and/or modified the standard saw a need for. Just because someone thinks it's a waste of space on the disk doesn't mean there weren't one or more opinions on the matter when the standard was agreed upon. In fact some member or members of the committee thought them useful enough for one purpose or another that they made there way into the standard. I say that anything not explicitly defined in a standard is open to interpretation and therefore can be either used for whatever purpose you desire or safely ignored until such time that it IS explicitly defined by the standard. From a software authoring perspective, 'mkudffs' Doesn't need to define what you should use these fields for, only provide a mechanism to allow you to use (or misuse dependent on perspective) them as you see fit, thus complying with the standard.


I think these values orientate on other specs, which themselfes try to generalize media mngt. In my example i will refer to Linux but this doesn't mean, it wouldn't apply to Windows. Those specs. are just hidden there.

Run the following cmd on Linux and look at the output: blkid

/dev/x: LABEL="Windows" UUID="?" TYPE="ntfs" PARTLABEL="Basic data partition" PARTUUID="?"

/dev/y: LABEL="Linux" UUID="?" TYPE="ext4" PARTLABEL="storage" PARTUUID="?"

As you can see, there are 2 description fields for every:

  • Partition
  • FileSystem on that Partition

In both cases, the first is the human readable description and the latter the machine description. Just like in the Domain Name System (DNS), since the machine description - the UUID - requires to be unique. So we can talk about n x 2 x 2 data fields, for partitions. But, since the optical media doesn't get partitioned, the raw media counts as partition itself. Which means there are 2 x 2 = 4 attributes, always. Lets try to fit the UDF properties into the above example:


I searched for hours and read many articles, but could't verify this. So this is just an assumption. But for the LVID it is assured by definition of the term and by trial. Linux and Windows, the latter with WinCDemu, use this property as label for the partition. Which, for optical media, is the medium itself.

It actually does fit pretty neat, but raises one question. There is an extra UUID property and i am tending to believe, that this is an implementation error of some kind. Because i once read on this network, that this was implemented later, because ppl. weren't able to mount UDF media by UUID. So it may have been a misunderstanding of the given property fields. I don't know where the current UUID is being put, but blkid reads this one as UUID. I don't know if this is a UDF driver or blkid problem. Maybe someone writes a mail with a hint to the corresponding person/group.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.