These are somewhat less organized Blu-ray Disc
specific usage notes. Idea is to introduce terminology, outline
options, explain some design choices...
The first thing about Blu-ray Disc
[hereafter BD] is its defect management system. Well, maybe
second, after its capacity:-) But first or second, defect
management is defined for both BD-RE, rewritable
media, and BD-R, write-once media. No, the latter part of
the last sentence is not a joke, it is defined even for
BD-R. Defect management comes with a performance penalty:
most units will typically record at about 1/2 of the advertised media
speed. This is because such units will spend every second revolution
verifying the newly recorded data for defects. Even though some would
argue to favour performance over the data integrity, I find it
inappropriate to leave your data "in the dark," and therefore
dvd+rw-tools are coded to favour the defect
management. On the positive side, even BD player units are required
to recognize and respect BD-R[E] defect relocation list.
This means that no explicit support by OS will be ever required to play
back BD recorded with defect control in effect. This is unlike "Mt.
Rainier" approach, which expects OS kernel to interpret the defect
lists upon playback. In other words there is hardly any reason to
bypass the BD defect management system.
BD-RE specification defines two basic
formats: with spare area reserved for remapping of media defects and
without [though the latter is optional]. If present, spare area
consists of two zones per layer: inner and outer. The inner zone of the
first layer is of fixed size of 256MB, while others are of variable
size, e.g. the outer zones size varies from 0 to 1GB each.
Dvd+rw-format allows the outer zone to be grown in 32MB
increments, but as of the moment of this writing you as the end-user is
responsible for making sure that the increased outer spare area does
not overlap with the end of the last data set. This brings us to the
following practical hints:
- when growisofs "runs into" a blank BD-RE media, it
automatically pre-formats it with minimal spare area of 256MB;
- if you want a larger spare area, run dvd+rw-format and
specify the desired spare area size with -ssa option, e.g.
'dvd+rw-format -ssa=1G /dev/dvd', preferably
prior to the actual recording;
- dvd+rw-format recognizes -ssa=max;
- dvd+rw-format also allows for -ssa=none, but [as mentioned earlier]
it is not recommended and might be unsupported by your unit.
BD-R specification defines following
recording modes:
- SRM, Sequential Recording Mode, applied to blank media without
any spare areas allocated;
- SRM applied to media explicitly pre-formatted with spare area[s];
- SRM with an option for Pseudo-Overwrite, SRM+POW;
- RRM, Random Recording Mode;
For brevity, let's refer to these four modes as SRM,
SRM-POW, SRM+POW and RRM. Even though it is
not explicitly mentioned above, both SRM+POW and RRM
require spare area[s] to be allocated. This is because overwrites
supported in these modes are handled as if they were defects,
i.e. by remapping the blocks to be overwritten through the defect list.
The exact difference between SRM+POW and RRM is beyond the
current scope. To provide enough room for such [well, RRM actually]
"overwrites" BD-R spare areas can be specified [depending
on application requirements] to be as large as 1/2 of the total media
capacity, yes, as much as 12GB per layer.
Now burn this into your mind:
- the recording mode and spare area size can be chosen/set only
once for given BD-R media prior to the
recording of the first user data block;
- when growisofs "runs into" blank BD-R media, it
automatically pre-formats it for SRM+POW with only inner spare area of
256MB;
- growisofs allows for SRM recordings without spare area through
"undocumented" -use-the-force-luke=spare:none
option, but it's not recommended;
- if you wish to allocate larger spare area or use
SRM-POW, use dvd+rw-format prior
to invoking growisofs;
As you might have noticed there is nothing about RRM
to burn into your mind. RRM is specified as optional and the unit I
have got unfortunately does not implement it. For this reason the
current version of dvd+rw-tools does not support RRM. You
surely wonder "all right, but why pre-format just for SRM+POW then?"
Recall that POW stands for Pseudo-Overwrite. Pseudo or not, it allows
us to effectively replace volume descriptors at the logical block
address 16 or, in other words, to grow ISO9660 volume within single
session - the same way it's done with DVD+RW,
DVD-RW Restricted Overwrite and DVD-RAM. This
means that data recorded at different occasions will be accessible even
on not-multisession-aware OSes. This is basically the reason for
favouring SRM+POW.
Given the BD media capacity, it would be interesting
to store files larger than 4GB in an ISO9660 volume. It should be noted
that the ISO9660 specification actually permits for files larger than
4GB, if they are broken into smaller extents. It is the single
extent size that is limited to 4GB[-2KB] by the
specification, not the whole file size. Unfortunately, mkisofs does not
currently support multiextent file layout, not to mention that
not all operating systems are capable to access such files. Therefore
you have to chop large files into several pieces prior to the
recording. Well, it is possible to burn bridge volume with large files
with -udf option, but then multisessioning is out of picture.