OPERATING SYSTEMS SUPPORT
UDF filesystem is natively supported by large amount of operating
systems. See following compatibility table:
┌────────────────────────────┬──────────────────────────┐
│ Operating system │ Maximum UDF revision for │
├─────────┬──────────────────┼────────────┬─────────────┤
│ Name │ Version │ read │ write │
├─────────┼──────────────────┼────────────┼─────────────┤
│ │ 2.3.17 – 2.4.5 │ 2.00 │ 2.00 │
│Linux │ 2.4.6 – 2.6.25 │ 2.01 │ 2.01 │
│ │ 2.6.26 (and new) │ 2.50 │ 2.01 │
├─────────┼──────────────────┼────────────┼─────────────┤
│ │ 98/Me │ 1.02 │ none │
│Windows │ 2000 │ 1.50 │ none │
│ │ XP │ 2.01 │ none │
│ │ Vista (and new) │ 2.60 │ 2.50 │
├─────────┼──────────────────┼────────────┼─────────────┤
│Mac OS │ 8.1 – 8.5 │ 1.02 │ none │
│ │ 8.6 – 9.2 │ 1.50 │ 1.50 │
├─────────┼──────────────────┼────────────┼─────────────┤
│ │ 10.0 – 10.3 │ 1.50 │ 1.50 │
│Mac OS X │ 10.4 │ 2.01 │ 2.01 │
│ │ 10.5 (and new) │ 2.60 │ 2.50 │
├─────────┼──────────────────┼────────────┼─────────────┤
│FreeBSD │ 5 (and new) │ 1.50 │ none │
├─────────┼──────────────────┼────────────┼─────────────┤
│NetBSD │ 4.0 │ 2.60 │ none │
│ │ 5.0 (and new) │ 2.60 │ 2.60 │
├─────────┼──────────────────┼────────────┼─────────────┤
│ │ 3.8 – 3.9 │ 1.02 │ │
│OpenBSD │ 4.0 – 4.6 │ 1.50 │ none │
│ │ 4.7 (and new) │ 2.60 │ │
├─────────┼──────────────────┼────────────┼─────────────┤
│Solaris │ 7 (and new) │ 1.50 │ 1.50 │
├─────────┼──────────────────┼────────────┼─────────────┤
│AIX │ 5.2 (and new) │ 2.01 │ 2.01 │
└─────────┴──────────────────┴────────────┴─────────────┘
Note that Windows 98 and Windows Me can read UDF filesystem only
from CD and DVD optical discs, not from hard disks.
BLOCK SIZE
In most cases, operating systems are unable to mount UDF
filesystem if UDF block size differs from logical sector size of
the device. Typically hard disks have sector size 512 bytes and
optical media 2048 bytes. Therefore UDF block size must match the
logical sector size of the device.
Linux kernel prior to version 2.6.30 used hardcoded UDF block
size of 2048 bytes independently of logical sector size,
therefore it was not able to automatically mount UDF filesystem
if block size differed from 2048. Since 2.6.30 and prior to 4.11
Linux kernel used a logical sector size of the device as UDF
block size, plus it tried fallback to 2048. Since 4.11 it uses
logical sector size and fallbacks to any valid block size between
logical sector size and 4096. Therefore since version 2.6.30
Linux kernel can automatically mount UDF filesystems correctly if
UDF block size matches device logical sector size and since
version 4.11 can automatically also mount devices which sector
size does not match UDF block size. In any case and also for
Linux kernel prior to version 2.6.30, different UDF block size
(which is not autodetected) can be manually specified via
bs=blocksize mount parameter.
WHOLE DISK VS PARTITION
UDF filesystem is supposed to be formatted on the whole media and
not to the partitioned hard disk. Mac OS X systems enforce this
rule and reject to automatically mount UDF filesystem unless it
is formatted on the whole unpartitioned hard disk. Possible
partition table (e.g. MBR or GPT) on disk with valid UDF
filesystem is ignored. On the other hand, Microsoft Windows
systems are unable to detect non-removable hard disks without MBR
or GPT partition table. Removable disks do not have this
restriction. A consequence is that non-removable hard disks
formatted to UDF by Windows Vista+ are not recognized by Mac OS X
systems and vice-versa. Note that manual mount of UDF partition
on partitioned hard disk on Mac OS X system is possible and
working (e.g. by running commands: mkdir /Volumes/DriveName &&
mount_udf /dev/disk1s1 /Volumes/DriveName). But there is no known
way to mount an unpartitioned non-removable disk on Windows
system.
Thanks to reserved and unused UDF boot area (first 32kB of UDF
filesystem) it is possible to deal with this problem, by putting
MBR on such non-removable hard disk just for compatibility
reasons with Windows. Such MBR table would contain one partition
which starts at sector 0 (includes MBR itself) and spans whole
disk device. So the whole disk device and also the first
partition on disk points to same sectors. Therefore UDF
filesystem can be mounted either from whole disk device (needed
for Mac OS X systems) or from first partition (needed for
Microsoft Windows systems).
Linux kernel ignores MBR table if contains partition which starts
at sector 0. Normally Linux kernel can detect and mount UDF
filesystem either on a partition or on whole disk device. It does
not have any restrictions.
mkudffs option --bootarea=mbr put such MBR table for
compatibility with Microsoft Windows systems into disk when
formatting.
LINUX LABEL BUGS
In most cases Logical Volume Identifier is used as UDF label. But
Linux libblkid prior to version 2.26 used Volume Identifier.
Therefore mkudffs --label for compatibility reasons set both
Logical Volume Identifier and Volume Identifier.
Linux libblkid prior to version 2.30 incorrectly processed non-
ASCII identifier strings encoded in 8-bit OSTA Compressed Unicode
format. Therefore mkudffs since version 2.0 for compatibility
reasons tries to encode a non-ASCII identifier strings in 16-bit
OSTA Compressed Unicode format and then fallbacks to 8-bit
format.
For more information about UDF Label and UUID see udflabel(8)
section UDF LABEL AND UUID.
