The UDF file system was standardized by the Optical Storage Technology Association to form a common file system for all optical media. The goal was to make a common file system for read-only media, and optical media that are re-writable. This is still the main goal for ongoing UDF standardization, although support for the more obscure WORM media is about to be limited, and support for non-optical media may be added.
When it was first standardized, the UDF file system was intended to replace ISO 9660, allowing support for both read-only and writable media. Almost directly after the first version of UDF was released, it was adopted by the DVD Consortium as the official file system for DVD Video and DVD Audio. Nowadays, a UDF file system may be found on most authored optical discs in the market, and on almost all recordable DVD media that are used for video recording.
As intended, initially UDF was mainly found on optical media. Most operating systems needed special third-party software to support reading it. Nowadays, almost all operating systems natively support at least reading UDF file systems, and many support some form of writing as well. Because of this increased support, UDF is gaining popularity on non-optical media that mainly need to be exchangeable, such as Iomega REV discs, large flash media, and even on hard disk drives.
DVD-Video media use UDF version 1.02. These discs contain a so-called UDF Bridge format, whereby both an ISO 9660 (Level 1) and a UDF 1.02 filesystem are present on the same disc, describing the same filesystem.
A UDF file system is normally mastered by authoring software in a batch process, and written to disc in a single pass. But when packet writing to rewriteable media, such as CD-RW, UDF allows files to be created, deleted and changed on-disc just as a general-purpose filesystem would on removable media like floppy disks and flash drives. This is also possible on write-once media, such as CD-R, but in that case the space occupied by the deleted files cannot be reclaimed (and instead becomes inaccessible).
The specification allows for nine character encodings: One by agreement, one specified by ECMA-6 (also known as ASCII), three subsets of ASCII, a subset of ECMA-94 (Latin-1), and various other graphical characters.
For next releases of UDF, changes are discussed in relation to using UDF on very large hard disk media, and using UDF on holographic storage media.
These builds are:
This format can be used on any type of disk that allows random read/write access, such as hard disks, DVD+RW and DVD-RAM media. Similar to other common file system formats, such as FAT, directory entries point directly to the block numbers of their file contents. When writing to such a disk in this format, any physical block on the disk may be chosen for allocation of new or updated files.
Since this is the basic format, practically any OS or File System Driver claiming support for UDF should be able to read this format.
To enable CD-R to be used virtually like a hard disk, whereby the user can add and modify files on a CD-R at will (so-called "drive letter access" on Windows), OSTA added the VAT build to the UDF standard.
The VAT is an additional structure on the disk that helps remapping physical blocks when files or other data on the disc are modified. The write-once nature of the media means that when a file is first added and then deleted on the disk, the file's data still remains on the disk. It does not appear in the directory any more, but special tools can be used to access the previous state of the disc (the state before the delete occurred), making recovery possible. Eventually the disk will be full, as free space cannot be recovered by deleting files. However, this behavior can be used to advantage for the purpose of archiving data.
Understanding the VAT structure is necessary in order to read such discs, but not all UDF file systems support VAT. See also "Why your computer might not read a particular UDF disk", below.
DVD-RW and CD-RW disks may thus be used as a blankable-R media but may also be formatted in the plain, VAT and Spared UDF builds.
However, it is important to understand that sectors of -RW media may "wear out" after a while, meaning that their data becomes unreliable, through having been rewritten too often (typically after a few hundred rewrites, with CD-RW).
If the plain build is used on a-RW media, file-system level modification of the data must not be allowed, as this would quickly wear out often-used sectors on the disc (such as for directory and block allocation data), which would then go unnoticed and lead to data loss. Hence, if software formats -RW media with UDF in the plain build, it should set the "hard write protection" flag on the volume to ensure that no UDF software attempts to overwrite files on the volume like it's possible with random-rewritable media such as hard disks.
To allow modification of files on the disc, the media can be used like -R media using the VAT build. This ensures that all blocks get written only once (successively), ensuring that there are no blocks that get rewritten more often than others. This way, a RW disc can be erased and reused many times before it should become unreliable.
To get true overwritability (which is not possible with the VAT build) of files on RW media, the disc needs to be formatted using the Spared build which adds an extra Sparing Table. This table keeps track of bad sectors and remaps them to working ones.
Once a -RW disc has been used with the spared UDF build, the disc should never get re-used with any other format, as the information about the bad blocks would get lost, potentially leading to the aforementioned unreliability.
Since DVD+RW discs can't emulate DVD+R, they can only be formatted in the plain and in the Spared UDF build.
Understanding Sparing Tables is necessary to be able to read discs written in Sparable build correctly. The problem is that some existing versions of UDF File System software ignore this extra information and treat such UDF discs as if they had the plain build. As long as the media has no worn-out sectors, this does not matter - the files can be read properly. But once sectors are remapped, a File System not paying attention to the Sparing Table will read outdated sectors, leading to retrieval of the wrong data.
An example is Mac OS X (10.4.5), which claims to support UDF 1.50 (see man mount_udf), yet it can only mount disks of the plain build properly (it cannot mount UDF disks with a VAT at all, see Sony Mavica problem, and while it appears to be able to mount CD-RWs written with a Sparing Table, it does not read its files correctly in the case that files are actually remapped).
|AIX 5.1, 5.2, 5.3|
|Linux 2.6||Version before 2.6.10 supported fewer media types.|
|Mac OS 9|
|Mac OS X 10.4||Can create UDF 1.50 (plain build) volumes using the drutil utility.|
|Mac OS X 10.5||To create, use "newfs_udf" utility|
|magnussoft ZETA 1.2.1|
|NetBSD 4.0|| Reading multi-session VAT, spared and metapartition variants|
from all CD, DVD and BD variants as well as HDD and Flash media.
|NetBSD 5.0|| Write support for all builds, including|
multi-session VAT but excluding metadata partition.
|Novell NetWare 5.1|
|Novell NetWare 6|
|OS/2||Additional fee drivers|
|Solaris 7 11/99+|
|Solaris 8, 9, 10|
|Windows XP/Server 2003||Write support only for DVD-RAM, not CD-R/RW or DVD+-R/RW|