WO2005055233A1

WO2005055233A1 - Method of, device and record carrier for power optimized defect management

Info

Publication number: WO2005055233A1
Application number: PCT/IB2004/052548
Authority: WO
Inventors: Wilhelmus F. J. Fontijn; Declan P. Kelly
Original assignee: Koninklijke Philips Electronics N.V.
Priority date: 2003-12-01
Filing date: 2004-11-25
Publication date: 2005-06-16
Also published as: TW200527386A

Abstract

The present invention relates to a scheme for defect management for an optical record carrier, for instance an SFFO disc, in a mobile environment. The record carrier comprises fragments of data, each fragment (Fn to Fn+2) comprising one or more blocks. A fragment has a size of approximately 5 MB and will be read and written in one sweep by the apparatus. Spare areas are present on the disc for re-mapping defect blocks to a spare area. These spare areas are located in the fringes of the fragments. The result is fully optimised to reduce power consumption without compromising the defect management. Associating a spare area with a fragment has the advantage that there will be no additional seek overhead, which will save power. Defect management can be implemented by the drive, so the application is unaware of the re-mapping. Real-time guarantees can be met, because reading a re-mapped block will not cause jumping in the program area of the disc. The spare area may only be read when needed.

Description

Method of, device and record carrier for power optimized defect management

The present invention relates to a record carrier, drive device and method of reading from or writing to the record carrier, such as an optical disc. In particular, the invention relates to an improved defect management scheme. Defect management is a major aspect of current storage solutions. Some hosts, e.g. a PC running Windows, require that certain storage devices expose a defect-free address space over the interface, even if the medium used is in fact not free of defects. The most common solution to this problem is that if a defect is detected, the storage device re-maps the , logical address of that location to another physical location. In case of an optical disc this other physical location can be located inside the lead-in area. The area which is reserved for alternative physical addresses is called the spare area. Sometimes the re-mapping interferes with the real-time aspects of the file that is stored. This might be the case, for instance, if during the streaming of a real-time file suddenly a block needs to be fetched from a physically distant location on the medium, because the sector it is in is re-mapped due to a defect in the original sector. A way of dealing with this problem is called slipping. Slipping is often used in the following way. After initialization and verification, a primary defect list is generated. Now, the mapping of the logical addresses on the physical addresses is adjusted, the defective locations are skipped and the addresses slip into the spare area. This works well for real-time applications, provided no new defects appear. Once the disc is actually used, the mapping of addresses is fixed. A recording medium having spare areas for defect management is known from document EP0997905. This document describes use of a plurality of spare areas including a spare area for slipping replacement and a spare area for linear replacement. The applicant has recently developed a miniature optical disc that records, plays back and erases data using precision blue lasers as being developed for the next generation of high-definition disc based video recorders. A system of the miniature optical disc is known as SFFO (Small Form Factor Optical) or Portable Blue (PB) and shows that it is possible to store 4 Gigabytes on a 3 -cm-disc, and to make a corresponding drive device as small as a memory card. However, in case of such a removable optical disc, e.g. SFFO, new defects are bound to appear during the lifetime of the disc. A way of dealing with this is to let the host allow the application to turn off the defect re-mapping leaving the application in control of handling the defects, for instance, by skipping sectors that are defective and writing the data intended for the defective sector in the next sector. The latter is a sort of 'real-time slipping'. Removable optical disc systems, like SFFO systems, impose a new limitation on optical storage. The disadvantage of the existing defect management schemes lies in the fact that they ignore the issue of power consumption. While for the SFFO system reducing the power consumption is crucial as it will often operate in a mobile environment, disconnected from main power. If the spare area would be in a physically distant location it would take too much power to retrieve the re-mapped data, as it would be required to jump each time a defect is encountered, and during the jump the laser (one of the most power consuming components) is switched on. In case of the SFFO system, traditional slipping is not an option as the SFFO will develop defects during usage. 'Real-time' slipping is not always an option as some applications are ignorant of the concept while they still need to be able to assume the address space to be defect-free. Another drawback of 'real-time slipping' is that typically a larger part of a file and/or fragment needs to be rewritten if a defect suddenly appears inside an area already written. An apparently obvious solution to this would be to cache the whole spare area in the drive. However, this would require a lot of expensive additional memory and the filling and upkeep of this memory would require additional power, even if the spare area is not actually or only partially used. In existing schemes the spare area is usually located at the beginning of the program area or at the end of a typical zone. Retrieving re-mapped data will consume much power because it is needed to jump from the data location to the spare area and back each time a defect is encountered.

It is an object of the invention to provide a record carrier, method and drive device for providing a defect management scheme with improved power saving characteristics. This object is achieved by a record carrier as claimed in claim 1, a writing method as claimed in claim 10, a reading method as claimed in claim 12, and a drive device as claimed in claim 13. Accordingly, a new form of defect management is provided with an optimized location for the spare area's and a power-optimized retrieval of re-mapped sectors. By including the spare area in or adjacent to the fragment read there will be no additional seek overhead, which reduces power consumption and leads to excellent real-time characteristics. The reading element, e.g. laser, can be shut down after the fragment has been read to save power. At the same time, the defect management can be implemented by the drive, i.e. the application need not be aware of re-mapping, while real-time guarantees can be met. Also, the spare area may only be read if needed. The program area may comprise a further fragment comprising a further spare area located at a boundary of said further fragment, the fragment and the further fragment are located adjacent to each other and said spare area of said fragment is located adjacent to said further spare area of said further fragment. In particular, the spare area and the further spare area may be combined to a combined spare area for re-mapping defect blocks of both said fragment and said further fragment. Thereby, one spare area can be allocated to a pair of two fragments, so as to minimize the total number of spare areas. This leads to a reduced number of sparing areas, as one area can be used by two neighboring fragments. Furthermore, a reserved spare area may be provided, said reserved spare area being located adjacent to the program area. Thereby, extra space can be provided for remapping in cases where no space is left in the respective associated or dedicated spare areas. The blocks in the fragments may be addressed by a logical address, wherein each block comprises a unique address. Then, the physical fragment is bigger than the logical fragment, due to the logically non-addressable spare area. Thereby, a well-defined interface to the storage device can be provided. A defect management table may be provided on the record carrier, said table comprising the unique logical address of the defect block and comprising a link to the physical sector associated with the defect block. Based on the information derived from the defect management table, it is known whether the next fragment to be read contains a remapped data, so that re-mapped data can be read in the same sweep. Further advantageous modifications are defined in the dependent claims.

The present invention will now be described on the basis of preferred embodiments with reference to the accompanying drawings, in which: Fig. 1 shows a schematic block diagram of a removable drive device with a standard interface and input function according to preferred embodiments of the present invention; Fig. 2a shows a schematic representation of an information area of a record carrier with a program area; Fig. 2b shows a schematic representation of a part of a program area according to a first preferred embodiment; Fig. 2c shows another schematic representation of a part of a program area according to a second preferred embodiment; Fig. 2d shows another schematic representation of a part of a program area according to a sthird preferred embodiment; Fig. 3 a shows a schematic representation of a part of an information area according to an example of the third preferred embodiment; Fig. 3b shows a schematic representation of a part of an information area according to another example of the third preferred embodiment; Fig. 4 shows a schematic flow diagram of a method for writing data on the record carrier; and Fig. 5 shows a schematic flow diagram of a method for reading data from the record carrier. Corresponding elements in different Figures have identical reference numerals and symbols.

The preferred embodiments will now be described in connection with a removable PB drive device which may expose a standard interface to legacy hosts such as a digital camera, a PDA or the like. In this connection, the term "legacy" is used to indicate those formats, applications, data or devices, which have been inherited from languages, platforms, and techniques earlier than the current technology. The legacy devices may not be well equipped to handle defects themselves. They may assume a defect free solid state memory. Fig. 1 shows a removable drive device 30 adapted e.g. to fit the Compact Flash form factor. Hence, the drive device 30 can be used to replace solid state memories. To achieve this, a standard interface unit 20 with corresponding connection terminals 32 is provided. The interface unit 20 may be arranged to map from an internal file systems used on an internal disc 10 to an external file system used for accessing the drive device 30 when writing to the disc 10 of the removable drive device 30, and to map from the internal file system to the external file system when reading from the disc 10. The PB logical format offers the opportunity to distribute the spare area over the disc. The read/write cycle of the PB system is based on fragments, to reduce power consumption. A fragment is a group of contiguous ECC (Error Correction Code) blocks that are read/written in one go or one sweep. Typically the buffer management of the PB system is tailored to this fragment-based access. By allocating all data needed for a particular task or time period in one fragment, the laser used in the optical unit of the drive device 30 can be shut down after the fragment is read to save power. The point is to have units that can be read in one sweep. If the application is running out of data in the buffer, another fragment is read. It should be clear that defect management is still performed by the drive device 30. The running applications just read the fragment and the drive device 30 will read the spare area if necessary. The physical fragment may thus be bigger than the logical fragment, i.e., physical fragment size = logical fragment size + spare area size. In other words, the storage or drive device 30 remains a bit engine with a well-defined interface between it and the host. The spare area cannot be accessed, e.g. addressed, through the interface unit 20. According to the preferred embodiments, a defect managing functionality or unit 22 is provided in the interface unit 20, which is adapted to use the first and/or last set of sectors or ECC blocks of a fragment as a spare area for the user data in the fragment. This enables a power-optimized defect management scheme offering excellent real-time characteristics. If during writing to a particular fragment the defect managing unit 22 detects a defect block, it will control the interface unit 20 to preferentially re-map that block to a block in the reserved area at the beginning or end of the fragment. During normal operation, data is read a fragment at a time. If from a defect management table provided on the disc 10, it is known that the next fragment to be read contains one or more re-mapped blocks in the spare area of the fragment, then these remapped blocks are read in the same sweep, causing almost no additional or minimal power usage or loss of time. The spare area is not read, if the fragment being read does not include re-mapped blocks, which ensures that the scheme does not impose additional overhead. This is based on the insight that the novel way the PB system administrates the use of the physical address space enables a new form of defect management, with an optimized location for the spare area's and a power optimized retrieval of re-mapped sectors. A drawback of traditional systems having many relatively small spare areas, is that even if no defects occur, jumps are needed to jump over the spare area after each fragment. This does not hold for the proposed system. During normal operation or at least in low power mode, the application will switch on the drive device 30, read a fragment and then shut off the drive device 30 for some time. It is not expected to read a sequence of fragments at a time, so that no extra jumping occurs. By including the spare area in the fragment read there will be no additional seek overhead, which reduces power consumption. At the same time, the defect management can be implemented by the drive, i.e. the application need not be aware of re-mapping, while real-time guarantees can be met. Also, the spare area may only be read if needed. It is noted that in PB systems the fragments are session or partition components used by the layers between the file system and the bit engine to manage the physical space. Not all fragments are in the logical space nor are all physical sectors that are part of a particular fragment. If the file system would take over the defect management the same distribution of spare areas is possible and optimal. So most of the proposed still holds. However, it is preferred that the defect management is performed by the drive device 30, e.g. by the defect managing means 22. Figs. 2a to 2d show schematic representations an information area provided on the disc 10 and of allocations of spare areas. Fig. 2a represents the information area IA of the PB disc 10, consisting of a

Lead-in LI, a drive navigation area DN, a rights management area RM, a defect management area DM, a first spare area SA1, a program area PA and a Lead -Out LO. Zooming in on the fragments, three possible configurations according to the first to third preferred embodiments are depicted in Fig. 2b, Fig. 2c and Fig. 2d, respectively. In the configuration of the first preferred embodiment shown in Fig. 2b, the spare area SA is formed by the last ECC blocks of each fragment which consists of a plurality of ECC blocks and may have a size of for example approximately 5MB. Furthermore, in the configuration of the second preferred embodiment shown in Fig. 2c in between each two fragments a spare area SA is provided consisting of the last blocks of the first fragment and the first blocks of the last fragment. Finally, the configuration of the third preferred embodiment shown in Fig. 2d is advantageous in that it minimises the number of spare areas SA. In the third preferred embodiment, the last blocks of fragment Fn and the first blocks of fragment Fn+1 form a common spare area SA, while in between fragment Fn+1 and Fn+2 no spare area is provided. It means, sets or pairs of two fragments share a spare area SA at the edge they share. For example, with a 1024 MB disc, 5 MB fragments and a reservation of 5% for defect remapping, 100 spare areas S A of 16 ECC blocks each would be required. Figs. 3a and 3b show schematic representations of two options or examples for the first spare area SA1 in the third preferred embodiment where the spare areas SA2 to

SA(¹ n+l), or the spare areas SA1 to SAV_(n+l), are shared by respective adjacent fragments comprising user data UD, as shown in Fig. 3a and Fig. 3b, respectively. The upward arrow indicates address "0" of the logical address space. Fig. 3a depicts a situation where extra space is reserved in the first spare area SA1 for defect re-mapping apart from the space reserved in user data fragments. Fig. 3b depicts a situation if this is not the case, i.e. no extra space is provided. The proposed defect management scheme requires a special mode of operation, which is described next based on the first option of the third preferred embodiment as shown in Fig. 3 a. The defect management table, detailing which blocks are re-mapped, is stored on the disc 10 in the designated defect management area (DM). It is read during the mounting or insertion procedure of the disc 10 and then cached. Fig. 4 shows a schematic flow diagram of a method for writing data on the disc 10. In step 101, a next fragment is started to be written. If during writing of the particular fragment the system detects a defective block in step 102, the system will re-map that block. It is then checked in step 103, whether the associated spare area of the present fragment is already filled or not. If not, the block is re-mapped to a block in the spare area which is shared with an adjacent fragment with which the present fragment forms a pair (step 105). This will be either at the beginning or end of the fragment. If it is detected in step 103 that there is no room left in the associated spare area inside the same fragment, it is checked in step 104 whether any space is left available in the spare area of an adjoining fragment of the same fragment pair. If so, re-mapping is performed to this adjacent spare area in the adjacent fragment (step 107). If this adjacent spare area is full also, an auxiliary re-mapping procedure is initiated in step 106, where it can be chosen between a real-time optimized re-mapping solution of using the nearest spare area with room or a long term power optimized solution of using the excess space in the first spare area SA1. The former minimizes the seek time, while the latter preserves space for future re- mappings within the same fragment. In step 108, the present fragment is written in one sweep. Finally, it is checked in step 109, whether a new fragment is to be written. If so, the procedure jumps back to step 101. Otherwise, the writing procedure comes to an end. Fig. 5 shows a schematic flow diagram of a method for reading data from the disc 10. During normal operation data is read a fragment at the time. First, the defect management table is read in step 201. If it is determined in step 202 from the defect management table that the next fragment to be read contains one or more re-mapped blocks and if it is then determined in step 203 that the re-mapped block(s) is(are) located in the spare area of the same or paired fragment, then the re-mapped data is read together with the user data of the fragment in the same sweep (step 204). If it is determined in step 203 that the re- mapped block is located elsewhere, i.e. not in the same fragment, a seek has to be preformed in step 205 to retrieve the re-mapped block. Then, in step 206, the fragment is read without its associated spare area. Finally, it is checked in step 207, whether a new fragment is to be read. If so, the procedure jumps back to step 201. Otherwise, the reading procedure comes to an end. In summary, a scheme is proposed for defect management for an optical record carrier, for instance an SFFO or PB disc, in a mobile environment. The record carrier comprises fragments of data, each fragment comprising one or more blocks. As examples, a fragment may have a size of approximately 2 MB, 5 MB, or 10 MB. Its maximum size is determined by the expected minimum size of the internal buffers of the drive. It will be read and written in one sweep by the apparatus. Spare areas are present on the disc for re-mapping defect blocks to a spare area. These spare areas are located in the fringes or borders of the fragments. The result is fully optimized to reduce power consumption without compromising the defect management. Associating a spare area with a fragment has the advantage that there will be no additional seek overhead, which will save power. Defect management can be implemented by the drive, so the application is unaware of the re-mapping. Real-time guarantees can be met, because reading a re-mapped block will not cause jumping in the program area of the disc. The spare area may only be read when needed. It must further be noted that the term "comprises/comprising" when used in this specification, including the claims, is taken to specify the presence of stated features, integers, steps or components, but does not exclude the presence or addition of one or more other features, integers, steps, components or groups thereof. It must also be noted that the word "a" or "an" preceding an element in a claim does not exclude the presence of a plurality of such elements. Moreover, any reference signs do not limit the scope of the claims; the invention can be implemented by means of both hardware and software, and several "means" may be represented by the same item of hardware. Furthermore, the invention resides in each and every novel feature or combination of features. The present application is not restricted to the above specific embodiments but can be used in any record carrier system where a defect management is performed based on a re-mapping operation of defect data portions. The preferred embodiments may thus vary within the scope of the attached claims.

Claims

CLAIMS:

1. A record carrier comprising an program area (PA) for storing data, said program area (PA) comprising a fragment and said fragment comprising a block, said fragment further comprising a spare area (SA) for re-mapping a defect block.

2. A record carrier as claimed in claim 1, wherein said spare area (SA) is located at a boundary of said fragment.

3. A record carrier as claimed in claim 1 or 2, wherein said program area (PA) comprises a further fragment comprising a further spare area (SA) located at a boundary of said further fragment, said fragment being arranged adjacent to said further fragment, and said spare area of said fragment being arranged adjacent to said further spare area of said further fragment.

4. A record carrier as claimed in claim 3, wherein said spare area and said further spare area are combined to a combined spare area for re-mapping defect blocks of both said fragment and said further fragment.

5. A record carrier as claimed in claim 1, further comprising a reserved spare area, said reserved spare area being located adjacent to said program area (PA).

6. A record carrier as claimed in claim 5, wherein said reserved spare area is arranged adjacent to said spare area of said fragment of said program area (PA).

7. A record carrier as claimed in any one of the preceding claims, wherein in said program area only said blocks in said fragments are addressable by a logical address and each said block comprises a unique address.

8. A record carrier as claimed in any one of the preceding claims, further comprising a defect management table comprising the unique logical address of said defect block and comprising a link to said spare area associated with said defect block.

9. A record carrier as claimed in any one of the preceding claims, wherein said record carrier is an SFFO or PB disc (10).

10. A method of writing data to a record carrier (10), said method comprising the steps of: a) writing said data in one sweep to a fragment comprising a block; b) re-mapping a defect block in said fragment to a spare area associated with said fragment in case a defect block is detected during writing.

11. A method as claimed in claim 10, further comprising the step of re-mapping a defect block in said fragment to an adjoining spare area associated with an adjoining fragment in case a defect block is detected during writing.

12. A method of reading data from a record carrier (10), said method comprising the steps of: a) reading a defect management table, said defect management table comprising a unique logical address of a defect block and comprising a link to a chosen spare area associated with said defect block; b) checking whether a fragment to be read comprises a defect block which is re-mapped to an associated spare area; and c) reading said fragment and said associated spare area in one sweep in case a defect block is re-mapped to said chosen spare area.

13. A drive device for providing access to a record carrier (10) as claimed in claim 1, said device (30) comprising reading means for reading data from said record carrier (10), said reading means being adapted to read at least one fragment in one sweep.

14. A device as claimed in claim 13, further comprising defect managing means (22) for re-mapping a defect block of data on said record carrier (10).