Data storage device shifting data chunks of alignment zone relative to sector boundaries

A data storage device (e.g., a disk drive or a solid state drive) comprises control circuitry and a non-volatile memory, such as a disk or a flash memory. The non-volatile memory comprises a plurality of memory segments referred to as sectors. To facilitate defect mapping, the sectors are accessed indirectly through logical block addresses (LBAs). In this manner, if a sector degrades, the system/user data can be relocated to a spare sector and the corresponding LBA(s) remapped to the spare sector.

The LBAs of a data storage device may be divided into a number of partitions, wherein each partition stores a file system (e.g., a n-bit FAT file system, or a NT File System) identifying system files and user files. A partition may be bootable meaning that it stores a bootable operating system (OS) such as Windows OS or Mac OS. When a computer system is initially powered on, a master boot record (MBR) is read from the data storage device (typically stored in the first logical data sector). The MBR identifies a partition table that stores a partition map for each partition of the data storage device. The partition table typically includes up to four primary partition maps identifying up to four primary partitions, wherein a primary partition may be further subdivided into extended partitions. Each partition map (primary and extended) identifies a starting LBA and ending LBA of the corresponding partition, a file system type field, and a flag indicating whether the partition is bootable. When the computer system finds a bootable partition, it uses the file system type field to access the partition's file system in order to read and execute the OS files from the partition (i.e., boot the computer system).

FIG. 1A shows a data storage device according to an embodiment of the present invention comprising control circuitry and a non-volatile memory comprising a plurality of sectors.

FIG. 1B shows an embodiment of the present invention wherein each sector stores eight host blocks, and a chunk is defined as comprises a plurality of sectors.

FIG. 1C is a flow diagram according to an embodiment of the present invention wherein at least one alignment zone in the non-volatile memory is defined as having a plurality of data chunks and pad chunks, wherein the pad chunks facilitate shifting the data chunks within the alignment zone.

FIG. 1D illustrates an embodiment of the present invention wherein the data chunks of an alignment zone are shifted right by three chunks, then left by two chunks, then left by one chunk while maintaining a copy of the data chunks.

FIG. 2 illustrates in more detail the process of shifting the data chunks right by three chunks, then left by two chunks, then left by one chunk while maintaining a copy of the data chunks.

FIGS. 3A-3D illustrate an embodiment of the present invention wherein the data chunks are shifted right by seven chunks corresponding to an offset of seven host blocks.

FIG. 4 is a flow diagram according to an embodiment of the present invention wherein boundaries of alignment zones are modified relative to partitions.

FIGS. 5A-5C illustrate an embodiment of the present invention wherein the end boundary of a first alignment zone and the beginning boundary of a second alignment zone are modified relative to first and second partitions.

FIG. 6 illustrates an embodiment of the present invention wherein the data storage device comprises a disk drive.

FIG. 7 illustrates an embodiment of the present invention wherein the data storage device comprises a solid state drive.

FIG. 1A shows a data storage device 2 according to an embodiment of the present invention comprising a non-volatile memory 4 comprising a plurality of sectors. The data storage device 2 further comprises control circuitry 6 operable to define at least one alignment zone in the non-volatile memory comprising a plurality of chunks including a plurality of data chunks and a plurality of pad chunks (an example is shown in FIG. 1D ), wherein each chunk comprises a plurality of sectors. Each sector is operable to store X host blocks (an example is shown in FIG. 1B ), the alignment zone comprises at least X−1 pad chunks, and the control circuitry 6 is operable to shift the data chunks of the alignment zone by a number of chunks equal to or less than X−1 plus a corresponding offset.

FIG. 1C is a flow diagram illustrating an embodiment of the present invention wherein after defining at least one alignment zone (step 8 ), the data chunks are first shifted right by N1 chunks (e.g., three chunks in FIG. 1D ) plus a first offset while maintaining at least one copy of the data chunks (step 10 ). The data chunks are then second shifted left by N2 chunks (e.g., two chunks in FIG. 1D ) plus a second offset while maintaining at least one copy of the data chunks (step 12 ), and then the data chunks are third shifted left by N3 chunks (e.g., one chunk in FIG. 1D ) plus a third offset while maintaining at least one copy of the data chunks (step 14 ), wherein the first, second, and third offsets represent different fractions of a sector, and the first, second, and third shifts are consecutive.

In the embodiment of FIG. 1B , each sector of the non-volatile memory 4 stores eight host blocks, wherein a logical block address (LBA) maps each host block to a physical block address (PBA) of a sector. In order to write a sector, the control circuitry writes eight host blocks (eight LBAs) to the corresponding PBA. If the LBAs of a write command do not align with the boundary of a sector, the control circuitry reads the sector, modifies the sector data with the new data, and then writes the modified sector data (read-modify-write). The read-modify-write operations are undesirable since it reduces the performance of the data storage device.

A write command may be misaligned with the sectors of the non-volatile memory 4 due to a number of reasons, such as if a host defines a file based on an LBA range that does not align with the sector boundaries. In one embodiment, a host accesses the data storage device based on a plurality of partitions defined in the non-volatile memory. If the boundaries of the partitions do not align with the boundaries of a sector, it is more likely the LBAs of the host files will also not align with the sector boundaries, thereby increasing the number of read-modify-write operations. Accordingly in one embodiment when a misalignment of write commands with the sector boundaries is detected, the data chunks of an alignment zone are shifted by an offset that corresponds to the misalignment. In the embodiment of FIG. 1B , the write commands may be misaligned with the sector boundaries by an offset of zero, one, two, three, four, five, six or seven host blocks (LBAs). In the embodiments of the present invention, each sector may store any suitable number of host blocks (e.g., four host blocks) so that there may be any suitable corresponding number of offsets (e.g., four offsets). In addition, in the embodiments of the present invention the offset for the write commands may change over time (e.g., if the partition boundaries are modified over time). When the offset of the write commands changes, the alignment zones are again shifted to account for the change in the offset.

FIG. 1D illustrates an example where an initial offset of three is detected for the write commands, and therefore the data chunks of the alignment zone are shifted right by three chunks. At some point a new offset of one is detected for the write commands, and therefore the data chunks of the alignment zone are shifted left by two chunks. Thereafter a new offset of zero is detected for the write commands, and therefore the data chunks of the alignment zone are shifted left again by one chunk. In the embodiments of the present invention, the pad chunks in the alignment zone enable the data chunks to be shifted right or left consecutively to accommodate any offset for the write commands that may be detected over time. The pad chunks also enable the data chunks to be shifted while maintaining a copy of the data chunks, thereby providing data protection during abnormal conditions, such as a power failure.

FIG. 2 shows further details of how the data chunks are shifted in an alignment zone for the example shown in FIG. 1D , including how a copy of the data chunks is maintained during the shifting operation. At step 16 , the alignment zone begins with an offset of zero such that all of the pad chunks (seven in this example) are on the right side of the alignment zone. Step 18 shows the beginning of the shifting operation to align the alignment zone with an offset of three. The last data chunk 48 in the alignment zone is copied over pad chunk 50 (three chunks to the right). While copying data chunk 48 over pad chunk 50 , data chunk 48 remains intact so that a copy of all the data chunks is maintained. The mapping information (LBA to PBA mapping) for accessing data chunk 48 also remains unchanged so that the original copy is used to service access requests (write/read) during the shift operation. After copying data chunk 48 over pad chunk 50 (step 20 ), the mapping information for data chunk 48 is changed to chunk 50 , and chunk 48 is converted into a pad chunk. This process is repeated at steps 22 and 24 for data chunk 52 and pad chunk 54 and so on until all of the data chunks have been shifted right by three chunks as shown in step 26 . After shifting the data chunks right by three chunks, there are three pad chunks on the left side of the alignment zone and four pad chunks on the right side of the alignment zone.

At step 28 a new offset of one is detected for the write commands, which means the data chunks need to be shifted left by two chunks. The shift procedure begins by copying the first data chunk 56 over pad chunk 58 (two pad chunks to the left). After copying data chunk 56 over pad chunk 58 (step 30 ), the mapping information (LBA to PBA mapping) for data chunk 56 is changed to chunk 58 , and chunk 56 is converted into a pad chunk. This process is repeated at steps 32 and 34 for data chunk 60 and pad chunk 62 and so on until all of the data chunks have been shifted left by two chunks as shown in step 36 . After shifting the data chunks left by two chunks, there is one pad chunk on the left side of the alignment zone and six pad chunks on the right side of the alignment zone.

At step 38 a new offset of zero is detected for the write commands, which means the data chunks need to be shifted left by one chunk. The shift procedure begins by copying the first data chunk 64 over pad chunk 66 (one pad chunk to the left). After copying data chunk 64 over pad chunk 66 (step 40 ), the mapping information (LBA to PBA mapping) for data chunk 64 is changed to chunk 66 , and chunk 64 is converted into a pad chunk. This process is repeated at steps 42 and 44 for data chunk 68 and pad chunk 70 and so on until all of the data chunks have been shifted left by one chunk as shown in step 46 . After shifting the data chunks left by one chunk, there are zero pad chunks on the left side of the alignment zone and seven pad chunks on the right side of the alignment zone.

In one embodiment of the present invention, the number of pad chunks in an alignment zone equals one less than the number of possible offsets that the data chunks may be shifted. In the example of FIGS. 1B and 1D , there are eight host blocks per sector and therefore there are eight possible offsets (0-7) and seven pad chunks to facilitate the offsets. In general, each sector is operable to store X host blocks, and an alignment zone comprises at least X−1 pad chunks. The control circuitry 6 is operable to shift the data chunks of an alignment zone by a number of chunks equal to or less than X−1 plus a corresponding offset. An alignment zone may comprise Y pad chunks at the beginning of the alignment zone and X−Y−1 pad chunks at the end of the alignment zone, where Y corresponds to a number of chunks the data chunks are shifted right in the alignment zone.

FIGS. 3A-3D illustrate an example embodiment wherein the offset detected for the write commands is seven meaning that the starting LBA of a write command is usually offset by seven host blocks (seven LBAs) relative to a sector as shown in FIG. 3B . In order to align subsequent write commands with a sector boundary, the LBA to PBA mapping of the alignment zone is shifted right by seven as shown in FIG. 3C meaning that the offset for the alignment zone is seven.

FIG. 3A shows the alignment zone prior to shifting the data chunks right by seven chunks. The alignment zone comprises a plurality of data chunks, each data chunk comprises a plurality of sectors, and each sector is accessed through LBAs 0 to N. In this example each sectors stores eight host blocks (accessed through eight LBAs) and therefore the alignment zone comprises at least seven pad chunks. The alignment zone also comprises an additional pad sector (PS) to facilitate shifting the LBA to PBA mapping. The pad sector (PS) is shown at the end of the alignment zone which corresponds to an offset of seven. If the offset is less than seven, the pad sector (PS) will be the first sector of the first pad chunk after performing the shift operation.

FIG. 3B shows further details of each sector accessed through a PBA (e.g., PBA — 0), wherein each LBA is mapped to an eighth of the sector (e.g., PBA — 0[0], PBA — 0[1] . . . PBA — 0[7] where PBA — 0 represents the first physical sector of a chunk). An “NA” is shown in place of the LBA for the sectors of the pad chunks and the pad sector meaning there is no LBA yet assigned to these sectors. FIG. 3C shows the LBA to PBA mapping after shifting the data chunks by seven chunks and after shifting the LBA to PBA mapping by seven LBAs. In the example of FIG. 3C , LBA 1 represents the start of a write command (e.g., at the start of a partition) which is aligned with the boundary of sector PBA — 1 of the first data chunk after shifting the data chunks. FIG. 3C also shows how the LBA sequence has been shifted into the sectors of the pad chunks as well as the pad sector (PS) (i.e., shifted by seven LBAs into the pad sector (PS) corresponding to the offset of seven).

FIG. 3D shows the alignment zone after shifting the data chunks right by seven chunks, wherein the last data chunk extends into the pad sector (PS). With an offset of seven, all seven pad chunks end up on the left side of the alignment zone. If, for example, an alignment zone is shifted with an offset of four, the data chunks would be shifted right by four chunks leaving four pad chunks on the left side of the alignment zone. The last data chunk of the alignment zone would extend into the first sector of the adjacent pad chunk by four host blocks (similar to the host blocks extending into the pad sector (PS) as shown in FIG. 3C ).

Including at least X−1 pad chunks in an alignment zone (where X is the number of host blocks stored in a sector) enables the data chunks of the alignment zone to be shifted left or right corresponding to any offset (e.g., offset 0-7) while maintaining at least one copy of the data chunks. In this manner, any change to the offset of write commands that may occur over time can be accounted for in a fail safe manner since there is always at least one copy of the data chunks. For example, the offset of write commands may change over time due to the boundaries of a partition map being modified over time. In the example of FIG. 1D , the offset of a partition map may initially be zero, and then change to an offset of three, and then change to an offset of two, and then change back to an offset of zero. Accordingly, the data chunks can be shifted right, and then shifted left, and then shifted left again as illustrated in FIG. 1D and FIG. 2 due to having at least X−1 pad chunks in the alignment zone.

FIG. 4 is a flow diagram executed by the control circuitry 6 according to another embodiment of the present invention wherein a plurality of alignment zones are defined including a first alignment zone and a second alignment zone (step 72 ), wherein each alignment zone comprises a plurality of chunks including a plurality of data chunks and a plurality of pad chunks, and each chunk comprises a plurality of sectors. A partition map is evaluated that defines a plurality of partitions including a first partition and a second partition, and each partition defines a start LBA and an end LBA (step 74 ). A boundary of the first alignment zone is modified relative to the end LBA of the first partition (step 76 ).

FIG. 5A shows an example where four alignment zones are defined Z1-Z4 each comprising a plurality of data chunks and a plurality of pad chunks. FIG. 5A also shows an example where two partitions are defined by a partition map, where each partition defines a start LBA and an end LBA. In this example, each alignment zone initially has the same number of data chunks which are aligned with an offset of zero (the data chunks are all shifted to the left side of each alignment zone). FIG. 5A also shows how the number of data chunks in an alignment zone does not integer divide into the size of a partition which means at least one alignment zone will straddle a partition boundary. Accordingly, in an embodiment of the present invention the boundaries of the alignment zones as well as the number of data chunks within each alignment zone are modified so that the number of data chunks integer divides into each partition.

FIG. 5B shows an example of how the boundaries of the alignment zones may be modified by shifting the ending boundary of alignment zone Z1 and the beginning boundary of alignment zone Z2. To facilitate modifying the boundaries, a number of data chunks in alignment zone Z2 are reassigned to alignment zone Z1 as shown in FIG. 5B . Reassigning the data chunks may include copying data in the data chunks of alignment zone Z2 to alignment zone Z1, or the data chunks may be reassigned without copying data (e.g., if a data chunk in alignment zone Z2 is empty). After modifying the boundaries and reassigning the data chunks, the number of data chunks in alignment zone Z1 covers the LBAs of the first partition, and the number of data chunks in alignment zones Z2-Z4 cover the LBAs of the second partition. The boundaries of the alignment zones may be modified in any suitable manner to achieve a similar result, such as by modifying the boundaries so that alignment zones Z1-Z2 cover the first partition and alignment zones Z3-Z4 cover the second partition.

In one embodiment, the partitions may define a starting LBA that results in a different partition offset relative to the sectors. In the example of FIG. 5C , the first partition may have a partition offset of two, and the second partition may have a partition offset of six. Accordingly in this example embodiment, the data chunks in the first alignment zone Z1 are aligned relative to a first partition offset defined by the first partition, and the data chunks in the second alignment zone Z2 (and Z3-Z4) are aligned relative to a second partition offset defined by the second partition. Aligning the alignment zones relative to the partition offset is implemented by shifting the data chunks in each alignment zone as described above.

The flow diagrams disclosed herein may be carried out by a microprocessor executing code segments of a program stored on a computer readable medium. Any suitable computer readable storage medium capable of storing code segments may be employed, such as the data storage device being aligned, or a separate data storage device, such as a disk drive, or a flash memory, or a CD.

The embodiments of the present invention may be used to align a partition of any suitable data storage device. FIG. 6 shows a data storage device in the form of a disk drive comprising a head 78 actuated over a disk 80 having a plurality of tracks 82 . The disk drive further comprises control circuitry 84 for receiving access commands from a host (write/read commands) and for generating a control signal applied to a voice coil motor (VCM) to rotate an actuator arm about a pivot in order to position the head 78 radially over the disk 80 to access a target track. Each track is divided into a number of sectors, wherein each sector is capable of storing multiple host blocks.

FIG. 7 shows a data storage device in the form of a solid state drive comprising a plurality of non-volatile semiconductor memories 86 A, 86 B, etc., such as flash memories, and control circuitry 88 for accessing the non-volatile semiconductor memories. In one embodiment, a sector of the solid state drive corresponds to a page of memory in a memory array, wherein each page stores a plurality of host blocks. A hybrid data storage device may also be employed comprising components of a disk drive shown in FIG. 6 combined with the non-volatile semiconductor memories shown in FIG. 7 .