All approved UDF 2.60 DCNs

More documents

Recommendations

Info

All approved UDF 2.60 DCNs Document: OSTA Universal Disk Format Subject: Clarify overlapping of Sparing Table with a partition Date: September 25, 2003; modified November 4, 2004 DCN-5107 Description: This DCN is for the next UDF revision after 2.50 and for the errata of UDF 1.50 thru 2.50. Sparing Area may overlap with a partition, but it is not clearly defined in UDF 1.50 thru UDF 2.50 whether instances of the Sparing Table may overlap with a partition or not. History of this DCN: In the UDF committee meeting, September 15, 2003 it was decided not to allow overlap of the Sparing Table with a partition and a DCN-5107 with that content and title “Sparing Table itself shall not overlap with a partition” was approved on December 8, 2003. However, it appeared that existing implementations were broken in this way. Therefore, it was decided in the meeting, November 4, 2004 to reopen DCN-5107 and reverse the previous decision and clearly define that overlap is allowed and how shall be acted in that case with respect to the Non-Allocated Space Stream. The DCN title was changed accordingly. For UDF 1.50, Non-Allocated Space List must be read instead of Non-Allocatable Space Stream. For UDF 1.50 thru UDF 2.01, section 2.2.11 must be read instead of 2.2.12. Change: In 2.2.12, in the 3 rd paragraph of page 38 replace: Available sparing areas may be anywhere on the media, either inside or outside of a partition. If located inside a partition, sparable space shall be marked as allocated and shall be included in the Non-Allocatable Space Stream. by: Available sparing areas and instances of the Sparing Table may be anywhere on the media, either inside or outside of a partition. If overlapping with a partition, the overlapping part shall be marked as allocated and shall be included in the Non- Allocatable Space Stream. All approved UDF 2.60 DCNs 24 February 28, 2005
All approved UDF 2.60 DCNs Document: OSTA Universal Disk Format Subject: Descriptor CRC Length Uint16 overflow rules Date: October 04, 2003; modified September 14, 2004 DCN-5108 Description: This DCN is for the next UDF revision after 2.50 and for the errata of the UDF revisions 1.02 thru 2.50. This issue was discussed in the UDF Committee meeting September 15, 2003. Mind that section numbers may differ for previous revisions. Since the definition of UDF, until now nobody seems to have been aware of the fact that the value of the Descriptor CRC Length can easily overflow for some descriptors. The default value for the CRC Length is (length of descriptor – 16), so if a descriptor length grows beyond 65551 (= 16 + MAX_UINT16) bytes, the CRC length does no longer fit in the Uint16 Descriptor CRC Length Field. Candidates for this are the descriptors that have a ‘no max’ length in the table of UDF section 5.1. However, the Sparing Table is missing in this table, and also has a “no max” length. This omission will also be repaired in this DCN. The ‘no max’ candidates are: Logical Volume Descriptor (LVD), Logical Volume Integrity Descriptor (LVID), Unallocated Space Descriptor (USD), Space Bitmap Descriptor (SBD) and Sparing Table (ST). The descriptors that practically can grow above a length of 65551 are the SBD and ST because: • For the LVD, 1017 Type 2 partition maps can be recorded before the LVD length grows beyond 65551 bytes. This could only occur for a multiple volume Volume Set. Such a Volume Set has the restriction of one partition map for each volume. • For the LVID, in the case of 8000 partition maps, still 1471 bytes are left for the Implementation Use field. UDF itself only needs 46 bytes for Implementation Use. • For the USD, there is room for 8190 extent_ad’s, which should be enough for the registration of unallocated space outside the partitions. The ECMA intent of the CRC is to detect descriptor damage. This is a valuable mechanism. For the Space Bitmap Descriptor (SBD), a CRC length of (descriptor length – 16) or 0 is allowed, because the bitmap can be updated very frequently, and it would be cumbersome to calculate the CRC over the whole descriptor for each bitmap change. For the Sparing Table (ST), only (descriptor length – 16) is allowed for the CRC length. The ST however is not updated frequently and a CRC calculation over the Map Entries is very valuable, e.g. for distinguishing between damaged an undamaged instances of the Sparing Table, in the case that a block (not the first one) of a ST instance is accidentally overwritten. Further the most important Map Entries of the ST are in the beginning, All approved UDF 2.60 DCNs 25 February 28, 2005
Page 1 and 2: All approved UDF 2.60 DCNs Base Doc
Page 3 and 4: All approved UDF 2.60 DCNs Document
Page 5 and 6: All approved UDF 2.60 DCNs Add note
Page 7 and 8: All approved UDF 2.60 DCNs Date: Au
Page 9 and 10: All approved UDF 2.60 DCNs Subject:
Page 11 and 12: All approved UDF 2.60 DCNs In 2.2.1
Page 21 and 22: All approved UDF 2.60 DCNs DCN-5104
Page 23: All approved UDF 2.60 DCNs Document
Page 27 and 28: All approved UDF 2.60 DCNs Replace
Page 33 and 34: All approved UDF 2.60 DCNs Figure 1
Page 35 and 36: All approved UDF 2.60 DCNs • Prio
Page 37 and 38: All approved UDF 2.60 DCNs BD-R can
Page 39 and 40: All approved UDF 2.60 DCNs 6.y.2 Re
Page 41 and 42: All approved UDF 2.60 DCNs 6.y.4 In
Page 49 and 50: All approved UDF 2.60 DCNs At the e
Page 53 and 54: All approved UDF 2.60 DCNs There sh
Page 55 and 56: All approved UDF 2.60 DCNs Foreign
Page 57 and 58: All approved UDF 2.60 DCNs replace:
Page 63: All approved UDF 2.60 DCNs Of the r

All approved UDF 2.60 DCNs

Create successful ePaper yourself

Delete template?

Save as template?