momo zone


BD defect management

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 forboth 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”option, but it’s not recommended;
  • if you wish to allocate larger spare area or use SRM-POW, use dvd+rw-formatprior 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, ifthey 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.



Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / 更改 )

Twitter picture

You are commenting using your Twitter account. Log Out / 更改 )

Facebook photo

You are commenting using your Facebook account. Log Out / 更改 )

Google+ photo

You are commenting using your Google+ account. Log Out / 更改 )

Connecting to %s

%d 博主赞过: