U.S. patent application number 14/668185 was filed with the patent office on 2015-12-03 for coded seeking apparatus and techniques for data retrieval.
The applicant listed for this patent is Massachusetts Institute of Technology. Invention is credited to Ulric J. Ferner, Muriel Medard.
Application Number | 20150348584 14/668185 |
Document ID | / |
Family ID | 51526065 |
Filed Date | 2015-12-03 |
United States Patent
Application |
20150348584 |
Kind Code |
A1 |
Medard; Muriel ; et
al. |
December 3, 2015 |
Coded Seeking Apparatus and Techniques for Data Retrieval
Abstract
Data blocks to be stored on a disk-based data storage device
(e.g., a hard disk drive, etc.) are coded together to form a
plurality of linearly independent network coded blocks. The network
coded blocks are then stored on the data storage device. Coded
seeking may then be used to retrieve the original data blocks from
the data storage device in a time-efficient manner. A read request
may be sent to the data storage device requesting an innovative
coded packet associated with the original data blocks. In response
to the read request, the data storage device may read an innovative
coded packet from the disk that is closest to current position of a
read element of the device.
Inventors: |
Medard; Muriel; (Belmont,
MA) ; Ferner; Ulric J.; (Cambridge, MA) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
Massachusetts Institute of Technology |
Cambridge |
MA |
US |
|
|
Family ID: |
51526065 |
Appl. No.: |
14/668185 |
Filed: |
March 25, 2015 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
13965645 |
Aug 13, 2013 |
9019643 |
|
|
14668185 |
|
|
|
|
61788746 |
Mar 15, 2013 |
|
|
|
Current U.S.
Class: |
360/49 |
Current CPC
Class: |
G11B 20/10481 20130101;
G11B 2020/10916 20130101; G11B 27/105 20130101; G11B 20/10
20130101; G11B 20/1217 20130101 |
International
Class: |
G11B 20/10 20060101
G11B020/10; G11B 27/10 20060101 G11B027/10; G11B 20/12 20060101
G11B020/12 |
Goverment Interests
GOVERNMENT RIGHTS
[0002] This invention was made with government support under
Contract No. FA9550-09-1-0196 awarded by the Air Force Office of
Scientific Research and under Contract No. W911NF-07-1-0029 awarded
by the Army Research Office. The government has certain rights in
the invention.
Claims
1. A method for use in retrieving data from a disk-based data
storage device having multiple network coded blocks stored therein
that are associated with a plurality of native data blocks, the
method comprising: determining that the plurality of native data
blocks need to be retrieved from the disk-based data storage
device; and sending a read request to the disk-based data storage
device requesting retrieval of an innovative coded block associated
with the plurality of native data blocks.
2. The method of claim 8, further comprising: receiving, in
response to the read request, an innovative coded block associated
with the plurality of native data blocks; temporarily storing the
innovative coded block associated with the plurality of native data
blocks in a memory; determining whether a sufficient number of
innovative coded blocks associated with the plurality of native
data blocks have been retrieved from the disk-based data storage
device to enable decoding to extract the plurality of native data
blocks; and if a sufficient number of innovative coded blocks
associated with the plurality of native data blocks have not been
retrieved from the disk-based data storage device to enable
decoding, sending another read request to the disk-based data
storage device requesting retrieval of an innovative coded block
associated with the plurality of native data blocks.
3. The method of claim 9, further comprising: repeating receiving,
temporarily storing, determining, and sending another mad request
until a sufficient number of innovative coded blocks associated
with the plurality of native data blocks have been retrieved from
the disk-based data storage device to enable decoding.
4. The method of claim 10, further comprising: decoding innovative
coded blocks to extract native data blocks therefrom after a
sufficient number of innovative coded blocks have been retrieved
from the disk-based data storage device.
5. The method of claim 8, wherein: the multiple network coded
blocks stored on the disk-based data storage device that are
associated with the plurality of native data blocks each include a
linear combination of the plurality of native data blocks.
6. The method of claim 12, wherein: the multiple network coded
blocks stored on the disk-based data storage device that are
associated with the plurality of native data blocks each include a
list of coefficients used to generate the corresponding linear
combination.
7. A method for storing data on a disk-based data storage device,
comprising: identifying a plurality of data blocks to be stored on
the disk-based data storage device, the plurality of data blocks
having N data blocks; generating a number of network coded blocks
using the plurality of data blocks, each network coded block
including a linear combination of the plurality of data blocks that
is generated using a different set of random coefficients from the
other network coded blocks; and writing the network coded blocks,
with corresponding random coefficients, to individual block
locations in the disk-based data storage device.
8. The method of claim 14, wherein: identifying a plurality of data
blocks to be stored on the disk-based data storage device includes:
acquiring a file to be stored on the disk-based data storage
device; dividing the file into a plurality of equal-sized block
windows that each contain N data blocks; and selecting one of the
plurality of equal-sized block windows.
9. The method of claim 15, further comprising: repeating generating
and storing for each block window in the plurality of equal-sized
block windows.
10. A system comprising: a processor; and a disk drive to store
digital data for access by the processor; wherein the processor is
configured to send a read request to the disk drive requesting
retrieval of an innovative coded block associated with a group of
native data packets.
11. The system of claim 20, wherein: the processor is configured to
continue to send read requests to the disk drive requesting
retrieval of innovative coded blocks associated with the group of
native data packets until enough innovative coded blocks have been
retrieved to enable decoding.
12. The system of claim 20, wherein the disk drive comprises: a
drive controller configured to: receive the read request requesting
retrieval of an innovative coded block associated with a plurality
of native data blocks; identify, in response to the read request,
an innovative coded block associated with the plurality of native
data blocks stored in the disk drive that is closest to a present
position of a read transducer of the disk drive; and read the
identified innovative coded block using the read transducer.
13. The system of claim 22, wherein: the drive controller is
configured to identify the innovative coded block that is closest
to the present position of the read transducer by selecting a
stored coded block that will take a least amount of time to
access.
14. The system of claim 22, wherein: the drive controller is
configured to identify the innovative coded block that is closest
to the present position of the read transducer by selecting a
stored coded block that is physically closest to the read
transducer.
15. The system of claim 22, wherein: the drive controller is
configured to ignore coded blocks associated with the plurality of
native data blocks that have recently been retrieved when
identifying an innovative coded block that is closest to the
present position of the read transducer.
16. The system of claim 20, wherein the disk drive comprises: a
drive controller configured to: acquire a plurality of data blocks
to be stored in the disk drive, the plurality of data blocks having
N data blocks; generate a number of network coded blocks using the
plurality of data blocks, each network coded block including a
linear combination of the plurality of data blocks that is
generated using a different set of random coefficients from the
other network coded blocks; and write the generated network coded
blocks, with corresponding random coefficients, to individual block
locations on one or more platters of the disk drive.
Description
CROSS REFERENCE TO RELATED APPLICATION
[0001] This application is a continuation of co-pending U.S.
application Ser. No. 13/965,645 filed Aug. 13, 2013 which claims
the benefit of U.S. Provisional Application No. 61/788,746 flied on
Mar. 15, 2013, both of which are incorporated by reference herein
in their entireties.
FIELD
[0003] Subject matter disclosed herein relates generally to data
storage and, more particularly, to techniques and systems for
increasing data access speeds in a data storage device using
coding.
BACKGROUND
[0004] The hard disk drive has been a staple of data storage
networks for some time. In the last two decades, the cost of hard
disk drives has steadily decreased while the density of data stored
on these drives has increased significantly, yielding cheaper and
higher capacity storage devices. Solid state storage devices have
also become increasingly popular, especially in portable devices,
owing to certain performance benefits. For example, the lack of
moving parts in solid state drives allows data read times to be
relatively constant across the device. In addition, there is no
physical read-head bottleneck in solid state drives. Conversely,
the physical movement of actuators, read/write heads, and platters
in hard disk drives can result in access times for a single block
of data that can be on the order of a few milliseconds to tens of
milliseconds in many instances. As such, hard disk drives can
create bottlenecks in modern input/output (I/O) systems.
[0005] The bottlenecks associated with hard disk drives have
motivated the development of numerous I/O latency reduction
algorithms for such drives. These algorithms include, for example,
read-ahead algorithms and more complex variants thereof. Typically,
these algorithms rely on scheduling schemes that predict and
exploit common access patterns. However, such algorithms are
failing to keep up with growing demands for I/O access speed
increases.
[0006] There is a general need for techniques that are capable of
reducing average access times in hard disk drives and other data
storage devices that have moving mechanical parts.
SUMMARY
[0007] In various embodiments described herein, techniques and
systems are provided that use coding to reduce average access times
in data storage devices that have moving mechanical parts (e.g.,
hard disk drives and other disk-based data storage devices). In at
least one embodiment, a simple internal coding scheme is provided
for disk-based data storage devices and systems that uses coding
across drive blocks to reduce average block read times. Coded
seeking may then be employed to read data from the data storage
device in a rapid and efficient manner. In a conventional disk
drive, a drive controller will typically seek and retrieve an
individual data block from a disk or platter in response to a read
request (e.g., a data block stored at a particular sector on the
disk). Using coded seeking, the controller may instead identify and
retrieve an innovative coded block that is closest to the position
of a read head in response to a read request. That is, for each
request that arrives at a disk controller, the controller may seek
one of many coded data blocks that contain useful information that
is closest to the current read head position, in a manner that
reduces average physical drive movement. In this fashion, average
seek times of individual data blocks can be reduced.
[0008] In accordance with one aspect of the concepts, systems,
circuits, and techniques described herein, a method is provided for
use in retrieving data from a disk-based data storage device having
multiple network coded blocks stored therein that are associated
with a plurality of native data blocks. More specifically, the
method comprises: receiving a read request requesting retrieval of
an innovative coded block associated with the plurality of native
data blocks; identifying, in response to the read request, an
innovative coded block stored in the disk-based data storage device
that is closest to a present position of a read transducer of the
disk-based data storage device; and reading the identified
innovative coded block.
[0009] In one embodiment, the multiple network coded blocks stored
on the disk-based data storage device that are associated with the
plurality of native data blocks each include a linear combination
of the plurality of native data blocks.
[0010] In one embodiment, the multiple network coded blocks stored
on the disk-based data storage device that are associated with the
plurality of native data blocks each include a list of coefficients
used to generate the corresponding linear combination.
[0011] In one embodiment, receiving a read request requesting
retrieval of an innovative coded block includes receiving a read
request requesting retrieval of a coded block that provides an
additional degree of freedom that is useful in decoding previously
retrieved coded blocks associated with the plurality of native data
blocks.
[0012] In one embodiment, receiving, identifying, and reading are
performed by a controller associated with the disk-based data
storage device.
[0013] In one embodiment, the disk-based data storage device has at
least N linearly-independent coded blocks stored therein, N being
the number of native blocks within the plurality of native data
blocks.
[0014] In one embodiment, the disk-based data storage device is a
magnetic disk drive.
[0015] In accordance with another aspect of the concepts, systems,
circuits, and techniques described herein, a method is provided for
use in retrieving data from a disk-based data storage device having
multiple network coded blocks stored therein that are associated
with a plurality of native data blocks. More specifically, the
method comprises: determining that the plurality of native data
blocks need to be retrieved from the disk-based data storage
device; and sending a read request to the disk-based data storage
device requesting retrieval of an innovative coded block associated
with the plurality of native data blocks.
[0016] In one embodiment, the method further comprises: receiving,
in response to the read request, an innovative coded block
associated with the plurality of native data blocks; temporarily
storing the innovative coded block associated with the plurality of
native data blocks in a memory; determining whether a sufficient
number of innovative coded blocks associated with the plurality of
native data blocks have been retrieved from the disk-based data
storage device to enable decoding to extract the plurality of
native data blocks; and if a sufficient number of innovative coded
blocks associated with the plurality of native data blocks have not
been retrieved from the disk-based data storage device to enable
decoding, sending another read request to the disk-based data
storage device requesting retrieval of an innovative coded block
associated with the plurality of native data blocks.
[0017] In one embodiment, the method further comprises: repeating
receiving, temporarily storing, determining, and sending another
read request until a sufficient number of innovative coded blocks
associated with the plurality of native data blocks have been
retrieved from the disk-based data storage device to enable
decoding.
[0018] In one embodiment, the method further comprises: decoding
innovative coded blocks to extract native data blocks therefrom
after a sufficient number of innovative coded blocks have been
retrieved from the disk-based data storage device.
[0019] In one embodiment, the multiple network coded blocks stored
on the disk-based data storage device that are associated with the
plurality of native data blocks each include a linear combination
of the plurality of native data blocks.
[0020] In one embodiment, the multiple network coded blocks stored
on the disk-based data storage device that are associated with the
plurality of native data blocks each include a list of coefficients
used to generate the corresponding linear combination.
[0021] In accordance with still another aspect of the concepts,
systems, circuits, and techniques described herein, a method is
provided for storing data on a disk-based data storage device. More
specifically, the method comprises: identifying a plurality of data
blocks to be stored on the disk-based data storage device, the
plurality of data blocks having N data blocks; generating a number
of network coded blocks using the plurality of data blocks, each
network coded block including a linear combination of the plurality
of data blocks that is generated using a different set of random
coefficients from the other network coded blocks; and writing the
network coded blocks, with corresponding random coefficients, to
individual block locations in the disk-based data storage
device.
[0022] In one embodiment, identifying a plurality of data blocks to
be stored on the disk-based data storage device includes: acquiring
a file to be stored on the disk-based data storage device; dividing
the file into a plurality of equal-sized block windows that each
contain N data blocks; and selecting one of the plurality of
equal-sized block windows.
[0023] In one embodiment, the method further comprises repeating
generating and storing for each block window in the plurality of
equal-sized block windows.
[0024] In accordance with a further aspect of the concepts,
systems, circuits, and techniques described herein, a disk drive
comprises: a drive controller; and at least one platter for storing
digital data under the control of the drive controller; wherein the
drive controller is configured to: (i) receive a read request
requesting retrieval of an innovative coded block associated with a
plurality of native data blocks from the at least one platter; (ii)
identify, in response to the read request, an innovative coded
block associated with the plurality of native data blocks stored on
the at least one platter that is closest to a present position of a
read transducer of the disk drive; and (iii) read the identified
innovative coded block from the at least one platter.
[0025] In one embodiment, the identified innovative coded block
read from at least one platter includes a linear combination of the
plurality of native data blocks and a list of coefficients used to
generate the linear combination.
[0026] In one embodiment, the at least one platter has at least N
linearly-independent coded blocks stored thereon that are
associated with the plurality of native data blocks, where N is the
number of native data blocks within the plurality of native data
blocks.
[0027] In accordance with a still further aspect of the concepts,
systems, circuits, and techniques described herein, a system
comprises: a processor; and a disk drive to store digital data for
access by the processor; wherein the processor is configured to
send a read request to the disk drive requesting retrieval of an
innovative coded block associated with a group of native data
packets.
[0028] In one embodiment, the processor is configured to continue
to send read requests to the disk drive requesting retrieval of
innovative coded blocks associated with the group of native data
packets until enough innovative coded blocks have been retrieved to
enable decoding.
[0029] In one embodiment, the disk drive comprises a drive
controller configured to: (i) receive the read request requesting
retrieval of an innovative coded block associated with a plurality
of native data blocks; (ii) identify, in response to the read
request, an innovative coded block associated with the plurality of
native data blocks stored in the disk drive that is closest to a
present position of a read transducer of the disk drive; and (iii)
read the identified innovative coded block using the read
transducer.
[0030] In one embodiment, the drive controller is configured to
identify the innovative coded block that is closest to the present
position of the read transducer by selecting a stored coded block
that will take a least amount of time to access.
[0031] In one embodiment, the drive controller is configured to
identify the innovative coded block that is closest to the present
position of the read transducer by selecting a stored coded block
that is physically closest to the read transducer.
[0032] In one embodiment, the drive controller is configured to
ignore coded blocks associated with the plurality of native data
blocks that have recently been retrieved when identifying an
innovative coded block that is closest to the present position of
the read transducer.
[0033] In one embodiment, the disk drive comprises a drive
controller configured to: (i) acquire a plurality of data blocks to
be stored in the disk drive, the plurality of data blocks having N
data blocks; (ii) generate a number of network coded blocks using
the plurality of data blocks, each network coded block including a
linear combination of the plurality of data blocks that is
generated using a different set of random coefficients from the
other network coded blocks; and (iii) write the generated network
coded blocks, with corresponding random coefficients, to individual
block locations on one or more platters of the disk drive.
BRIEF DESCRIPTION OF THE DRAWINGS
[0034] The foregoing features may be more fully understood from the
following description of the drawings in which:
[0035] FIG. 1 is a block diagram illustrating an exemplary
computing system that may incorporate features described
herein;
[0036] FIG. 2 is a top view of an exemplary disk drive that may
incorporate features described herein;
[0037] FIG. 3 is an exemplary plot illustrating how an expected
value of a data access time of a coded block (E[T.sub.1]) may vary
with a number of native data blocks r used to generate the coded
blocks for different values of w in accordance with an
embodiment;
[0038] FIG. 4 is a exemplary plot illustrating how E[T]/E[T.sub.n]
may vary as a disk drive implementing coded seeking moves along a
block window's degrees of freedom in accordance with an
embodiment;
[0039] FIG. 5 is a flow diagram illustrating a method for storing
data on a disk drive using network coding in a manner that supports
coded seeking in accordance with an embodiment;
[0040] FIG. 6 is a flow diagram illustrating a method for use in
retrieving data from a disk drive using coding seeking in
accordance with an embodiment; and
[0041] FIG. 7 is a flow diagram illustrating a method for use in
retrieving data from a disk drive that supports coding seeking in
accordance with an embodiment.
DETAILED DESCRIPTION
[0042] Coding has long been used in hard disk drives for error
correction within single blocks. Codes such as, for example,
Reed-Solomon codes, low density parity check (LDPC) codes, and
others are among the most commonly used in disk drives. However,
coding has not been used to reduce I/O latency in hard drives.
Techniques and systems are described herein that use coding to
reduce average access times in hard disk drives and other data
storage devices that have moving mechanical parts. The techniques
and systems may be used in addition to, or as a replacement for,
read-ahead algorithms and other I/O latency reduction
algorithms.
[0043] FIG. 1 is a block diagram illustrating an exemplary
computing system 10 that may incorporate features described herein.
As illustrated, the computing system 10 may include, for example, a
digital processor 12, memory 14, and a disk drive 16. The digital
processor 12 may use the disk drive 16 to store, for example,
program files and data files in a nonvolatile form. The digital
processor 12 may use the memory 14 to store, for example, programs
that are currently being executed by the processor 12. As
illustrated, digital processor 12 may execute an operating system
18 to control the overall operation of the system 10. Digital
processor 12 may also execute one or more application programs 20.
The digital processor 12 may include any type of processor that is
capable of processing computer instructions including, for example,
a general purpose microprocessor, a digital signal processor (DSP),
a reduced instruction set computer (RISC), a microcontroller,
and/or others, including combinations of the above.
[0044] As shown in FIG. 1, the disk drive 16 may include: a drive
controller 22, a drive cache (or buffer) 24, and one or more
platters 26. The drive controller 22 controls the operation of the
disk drive 16. As such, the drive controller 22 may include one or
more digital processing devices. The platters 26 are the storage
media where the digital data is stored within the disk drive 16. In
a magnetic disk drive (e.g., a hard disk drive, etc.), each of the
platters 26 may be coated with a magnetic material that allows
digital data to be stored thereon in a magnetic form (e.g., as
magnetic polarity inversions or some other magnetic indicia). Data
is typically stored within concentric tracks on the surfaces of the
platters 26, although other schemes also exist. Data may be stored
on one or both sides of each platter 26. A disk drive may include
only a single platter, but typically a number of platters will be
stacked one above the other on a central spindle that serves as an
axis of rotation for the platters 26 during disk drive operation.
Read and write elements may be used as transducers to read data
from and write data to the tracks of the platters 26.
[0045] The drive cache 24 may be used as a data buffer between the
platters 26 and an exterior device (e.g., processor 12, etc.)
during read and write operations. Drive cache 24 may thus operate
to provide, among other things, temporary data storage for read
and/or write data to compensate for a difference in data rate
between a read/write channel associated with the platters 26 and an
input/output port of the drive 16. The drive cache 24 will
typically be able to store a maximum of C blocks at any given
time.
[0046] Each active platter surface within a disk drive will
typically have one read element and one write element associated
therewith. In some cases, a single element may be used to perform
both reading and writing for a platter surface, but typically
separate read and write elements will be provided (although they
may both be part of the same read/write head). The read and write
elements are usually coupled to the end of a moveable actuator arm
that allows them to be controllably positioned with respect to the
surface of the corresponding platter. A voice coil motor or other
type of motor may be used to move the actuator arm under the
control of the drive controller 22. Data is usually stored on disk
drive platters in fixed length blocks that are at known locations
on the platter surface (i.e., a known point on a corresponding
track). Servo information may also be provided on the surface of
the disk platter for use in positioning the read or write element
during corresponding access operations.
[0047] During disk drive operation, the platters 26 are rotated
about the central axis at a predetermined rate. Typically, the
drive controller 22 will receive a read or write request from an
external source (e.g., from operating system 18 of processor 12,
etc.) and will carry out the request by reading a block of data
from the drive (for a read request) or writing a block of data to
the drive (for a write request). For both read and write requests,
the drive controller 22 will first cause the corresponding read or
write element to seek to the appropriate track. After the element
is centered on the track, the drive controller will wait for the
platter to rotate a sufficient amount to place the desired block
location (or sector) of the track under the read or write element
and then allow the data to be read from or written to the block
location.
[0048] A disk drive is typically a random access storage device.
That is, at any time, a single data block may be read from or
written to any block location or sector on any of the active
platter surfaces. In one disk drive standard, known as the Advanced
Format Standard, the individual data blocks are of size 4096 bytes.
Other sizes may be used in other standards. In a common write
technique, a data file to be stored on a disk drive may be divided
into a plurality of blocks, each having the appropriate block size.
For example, a single file f may be decomposed into a set of
{f.sub.i}.sub.i=1.sup.M data blocks. The individual blocks may then
be stored to available block locations on the disk platters. A
record will be maintained that tracks the locations of the various
blocks associated with the file on the disks. In many cases, the
available block locations on the platter surfaces may not all be
grouped together. Thus, the locations where the blocks are stored
on the disk surfaces will not necessarily be near one another. That
is, the blocks associated with the file may, in some cases, be
distributed across the surfaces of one or more platters.
[0049] In a common read scenario, the drive controller 22 will
receive block requests from the operating system 18 at an input
thereof. When a read request arrives at the controller 22 for a
block f.sub.i, the controller 22 may first check whether or not
f.sub.i is currently located in the drive cache 24. If it is, the
controller 22 will cause the block f.sub.i to be transferred from
the cache 24 to the operating system 18 in response to the request.
This may be considered an instantaneous transfer in comparison to a
typical disk read operation and can speed up the read process
considerably. If block f.sub.i is not located in the cache 24, then
the block will be read from the platters 26 with a random block
access-time T. The block access-time T may be expressed as:
T=wR.sub.1+R.sub.2+e (1)
where R.sub.1 is the rotational latency, R.sub.2 is the seek time,
w.epsilon.R is the ratio between the speed of angular rotation of
the platter and the rotational movement of the head, and e is the
controller processing and block read-out time. Using this approach,
the read process can be modeled as a GI/G/1/D queue, where D is a
function of the cache size and the average service rate is given by
1/E[T]. As can be appreciated, if the blocks associated with a file
are randomly distributed across the platters of a disk drive, the
process of individually reading all of the blocks associated with
the file from the disk drive can be very time consuming.
[0050] In various embodiments described herein, network coding is
used to store data to the platters of a disk drive in a manner that
allows read operations to be performed in a faster, more efficient
manner. This read technique may be referred to as coded seeking.
Instead of storing the raw data blocks f.sub.i associated with a
file f to corresponding locations on the platter surfaces, network
coded blocks of data associated with the file are stored. Network
coding is a technique where data is encoded by generating linear
combinations of data elements. These linear combinations may later
be "decoded" to extract the original data elements. The decoding
process typically requires that a sufficient number of linear
combinations (and/or original data elements) be available as
"degrees of freedom" to solve for the original data elements using
linear techniques.
[0051] One popular form of network coding is known as random linear
network coding (RLNC). Using RLNC, data elements are linearly
combined using randomly generated coefficients. If different sets
of randomly generated coefficients are used to generate different
linear combinations of the same data elements, the resulting linear
combinations will typically be linearly independent of one another
(i.e., they will be innovative) and will thus each represent a
degree of freedom that may be used in decoding.
[0052] In one possible technique for coded storage, a file f may be
separated into L equal-sized "block windows" or generations that
each contain r data blocks. The Lth block window of the file may be
referred to as B.sub.l. Block window B.sub.l may include a subset
of the file's block indices and be disjoint from all other block
windows associated with the file. A coded block c.sub.i may be
generated for block window B.sub.l, as follows:
c.sub.i=.SIGMA..sub.k.epsilon.B.sub.l.alpha..sub.kf.sub.k (2)
where .alpha..sub.k are random coefficients and f.sub.k are the
data blocks associated with block window B.sub.l. A number of
different coded blocks c.sub.i may be generated for each block
window B.sub.l. The coefficients .alpha..sub.k may be drawn from a
finite field F.sub.q of size q, such that the individual coded
blocks c.sub.i associated with a block window B.sub.l are linearly
independent of one another with high probability and in some cases
certainty. Each coded block c.sub.i will thus provide partial
information on all data blocks in the corresponding block window.
The coded blocks associated with each block window of the file f
will be stored to the platters of the disk drive. The number of
coded blocks c.sub.i that are generated and stored for each block
window will be at least a number required to solve for all of the
data blocks of the block window, but it could be more than this
number. The coefficients .alpha..sub.k used to generate each coded
block may be stored on the disk surfaces in association with the
coded block (e.g., as meta data or in some other manner).
[0053] When the operating system 18 eventually wants to read the
file f from the disk drive 16, it may read each of the block
windows from the disk drive 16 one by one until all block windows
have been recovered. For each block window, the operating system 18
will send read requests to the drive controller 22 asking for
innovative coded blocks (or degrees of freedom) associated with the
block window. For each read request, the drive controller 22 may
retrieve one coded block along with the coefficients associated
with the coded block. The operating system 18 may continue to send
requests for innovative coded blocks until a sufficient number of
degrees of freedom have been retrieved to decode the data blocks of
the block window. Any technique for decoding network coded data
blocks may be used to decode the coded blocks. In at least one
implementation, a progressive decoding technique may be used by the
operating system 18 to decode coded blocks as they are received,
such as Gauss-Jordan elimination or a similar technique. Other
techniques may alternatively be used. As will be described in
greater detail, the techniques used by the drive controller 22 to
retrieve the coded blocks (or degrees of freedom) can speed up the
overall retrieval of the file f considerably.
[0054] The drive controller 22 may have a record of the locations
on the platters of all coded blocks associated with each block
window of each stored file. When a read request for an innovative
coded block associated with a particular block window of a
particular file is received, the drive controller 22 may determine
which of the corresponding coded blocks stored on the platters is
closest to a current position of a read head of the disk drive 16.
The drive controller 22 may then seek to the corresponding track on
the corresponding platter surface and read that coded block. When a
next read request for an innovative coded block associated with the
same block window of the same file is received, the drive
controller 22 may determine which of the other corresponding coded
blocks stored on the platters is closest to the current position of
the read head of the disk drive 16. The same procedure may then be
repeated for each new request. Thus, in some implementations, the
drive controller 22 may keep track of recently retrieved data so
that the same coded block associated with a given block window is
not sent twice to the operating system during the same file read
operation (this is because the same coded block read a second time
will not provide a new degree of freedom for use in decoding).
Because the "closest" coded block is used for each read request, a
significant amount of seek and latency time may be avoided during a
file read operation.
[0055] In some implementations, the drive controller 22 may first
determine whether an innovative coded block associated with the
identified block window is currently stored within the drive cache
24 before retrieving a coded block from the platters. If there is a
coded block associated with the identified block window in the
drive cache 24, and the coded block has not already been sent to
the operating system 18 during the current file read operation,
then the coded block may be sent from the drive cache 24 to the
operating system 18 in response to the read request.
[0056] In a typical scenario, when the operating system 18 sends a
request for a degree of freedom for a block window B.sub.l, the
read head and platters of the corresponding disk drive will be in a
random physical orientation with respect to one another. FIG. 2 is
a top view of a disk drive 30 showing such a situation. As
illustrated, disk drive 30 includes a platter 32 that is rotating
in a direction 34, a read element 36 coupled to the end of an
actuator arm 38, and a voice coil motor 40 to pivot the actuator
arm 38 about an axis under the control of the disk controller. When
the read request is received, the read element 36 may be in a
random position with respect to the various coded blocks stored on
the platter. The drive controller may then determine which of the
various coded blocks on the platter is closest to the current
position of the read element 36. In different embodiments, the term
"closest" can mean either physically closest (i.e., shortest
distance between coded block and read element) or closest in time
(i.e., the block the read element can be moved to the soonest).
Techniques to find the closest block may include computing the
distance or time required to travel to each block in a list and
finding the minimum element from that list. The distance or time
calculations would be based on the current location of the head and
the physical location of each block. To compute the order to access
all blocks in a window optimally, a solution or approximate
solution of the well known Traveling Salesman Problem (TSP) may be
sought. More specifically, each block may be considered an element
in an undirected weighted graph. The potential head and platter
movements can then be modeled as paths in the graph, with weights
being a function of distance or time to travel.
[0057] After a closest coded block c.sub.n has been identified, the
drive controller may cause the actuator arm 38 to pivot until the
read element 36 is centered above and following a track 42
associated with the coded block (this is known as a seek
operation). The drive controller may use servo information read
from a surface of the platter 32 to track a current position of the
read element 36 during this process. Once the read element 36 is on
the appropriate track 42, the drive controller will wait until the
platter 32 turns to a point where the read element 36 is above the
desired coded block c.sub.n. The time delay between the read
element reaching the track 42 and the desired coded block reaching
the read element 36 is known as the rotational latency. When the
read element 36 reaches the desired coded block on track 42, the
drive controller may read the coded sector (and the corresponding
coefficient information) from the platter surface. This process may
then be repeated for each other coded block to be read.
[0058] As described previously, in many cases, the coded blocks
associated with a block window may be spread randomly on one or
more platter surfaces. As each read request is received, the disk
controller may select and retrieve the next "closest" innovative
coded block stored in the drive. Using the same form as equation
(1) above, the random access time T.sub.n for the nth coded block
(or nth degree of freedom) may be expressed as:
T.sub.n=wR.sub.1,n+R.sub.2,n+e, (3)
where R.sub.1,n is the rotational latency for the nth coded block
and R.sub.2,n is the seek time for the nth coded block.
[0059] As described above, when a read request is received, the
drive controller may determine which coded block is closest to the
read element and then read that coded block. The time required to
move the read element to the beginning of this block is linearly
related to both the angle the actuator arm must turn to align the
read element with the track of the coded block and the distance the
read element must then move along this track to the beginning of
the coded block of interest. In one possible approach, the
parameter .theta..sub.2,n. (see FIG. 2) may be expressed as the
proportion of a full range of motion that the actuator arm 38 must
turn to position the read element above the relevant track 42 for
the nth coded block c.sub.n and the parameter .theta..sub.1,n may
be expressed as the proportion of a full rotation that the platter
32 must turn to read out the nth coded block ca once on the
relevant track 42.
[0060] If R.sub.1 and R.sub.2 are assumed to refer to the same
coded block, and if the rotational latency and the seek time for
each block are statistically independent, then for the first coded
block associated with a block window, R.sub.1,1 and R.sub.2,1, the
access-time T.sub.1 may be computed as:
R.sub.1,1=min(.theta..sub.1,1, . . . ,.theta..sub.1,r) (4)
and
R.sub.2,1=min(.theta..sub.2,1, . . . ,.theta..sub.2,r). (5)
where the minima apply to the same coding block. Since both
R.sub.1,1 and R.sub.2,1 are minima of a fixed number of uniform
random variables, their PDF have the common form:
f(r.sub.i,1)=r(1-r.sub.i,1).sup.r-1. (6)
The expected value of T.sub.1 is then given by:
E [ T 1 ] = w + 1 r + 1 + E [ e ] . ( 7 ) ##EQU00001##
Therefore, as r increases, the speed of the disk drive in accessing
random degrees of freedom also increases. It should be noted that
as r tends toward infinity, the value of E[T.sub.1] tends toward
E[e]. In modern hard disk drives, the seek time and rotational
latency can account for approximately two-thirds of total read
time. Therefore, in practical systems, it is possible that
significant speed gains can be achieved using the described
techniques. FIG. 3 is a plot illustrating how E[T.sub.1] varies
with r for a number of different values of w.
[0061] As described above, the coded blocks associated with a block
window may be stored on a single platter surface of a disk drive or
on multiple platter surfaces. If multiple platter surfaces are
used, similar techniques may be used to identify a coded block that
is closest to a present location of a read element. That is, a
coded block may be selected for a next read operation that will
minimize an access time for the operation.
[0062] If content is coded across r blocks, then all r blocks need
to be accessed for the corresponding block window to be decoded. In
general, coded-seeking gains will be greatest for the first degree
of freedom accessed and will decrease for subsequent degrees of
freedom. For the last degree of freedom, the coded seeking system
access-time may be equivalent to the uncoded scheme. The ratio
E[T]/E[T.sub.n] may be used as a metric for gauging the speed-up
gains that diminish with n. As an approximation, the parameter r
may be substituted for r-n+1 in equation (7) above. FIG. 4 is an
exemplary plot illustrating how E[T]/E[T.sub.n] may vary as a disk
drive moves along a block window's degrees of freedom.
[0063] The speed-up of the seek-time may have additional benefits,
including reducing blocking probability. In particular, if we model
the disk drive as a GI/G/1/D queue, then for an uncoded system we
have a blocking probability P.sub.b.sup.C proportional to:
P b U .varies. E [ T ] .lamda. .lamda. 1 .lamda. D - 1 .mu. 1 .mu.
D - 1 , ( 8 ) ##EQU00002##
where .lamda..sub.i and .mu..sub.i are the ith moment for arrival
and service rates, respectively. The equivalent coded seeking
blocking probability P.sub.b.sup.C for the first degree of freedom
is then proportional to:
P b C .varies. P b U ( w + 1 ) / ( r + 1 ) + E [ e ] ( w + 1 ) / 2
+ E [ e ] ( 9 ) .apprxeq. 2 r + 1 P b U ( 10 ) ##EQU00003##
If E[e] is small.
[0064] The speed-up of hard disk drives and the reduction in
blocking probability that are made possible through the use of
coded seeking tend to reduce the dependence on physically moving
parts within a disk drive. In various embodiments, this technique
may require the operating system to store multiple coded blocks and
decode the blocks when sufficient degrees of freedom have been
read. In essence, work originally done by the disk drive is
transferred to either the operating system or the drive controller
and can thus be performed using fast RAM or the fast cache,
respectively. The benefits of coded seeking are most apparent when
requests are uniformly random. When there is more structure to
requests, the advantages of coded seeking may be outweighed by the
disadvantages of having to perform coded writing. The size of the
block window that is used to perform coded seeking can affect the
overall benefit of the technique. If the block window is too small,
for example, the benefits of coded seeking will diminish. If the
block window is too large, the decoding delay may increase. The
best block window size to use in a particular system will be
related to the storage unit size, the file size, and the operating
system timing and delay guarantee requirements.
[0065] FIGS. 5, 6, and 7 are flow diagrams showing various example
processes for implementing coded seeking in a disk drive in
accordance with embodiments.
[0066] The rectangular elements in the flow diagrams (typified by
element 52 in FIG. 5) are herein denoted "processing blocks" and
may represent computer software instructions or groups of
instructions. It should be noted that the flow diagrams of FIGS. 5,
6, and 7 represent exemplary embodiments of a design described
herein and variations in such a diagram, which generally follow the
process outlined, are considered to be within the scope of the
concepts, systems, and techniques described and claimed herein.
[0067] Alternatively, the processing blocks may represent
operations performed by functionally equivalent circuits such as,
for example, a digital signal processor circuit, an application
specific integrated circuit (ASIC), or a field programmable gate
array (FPGA). The flow diagrams do not depict the syntax of any
particular programming language. Rather, the flow diagrams
illustrate the functional information one of ordinary skill in the
art may require to fabricate circuits and/or to generate computer
software to perform the corresponding processing. It should be
noted that many routine program elements, such as initialization of
loops and variables and the use of temporary variables, are not
shown. It will be appreciated by those of ordinary skill in the art
that, unless otherwise indicated herein, the particular sequences
described are illustrative only and can be varied without departing
from the spirit of the concepts described and/or claimed herein.
Thus, unless otherwise stated, the processes described below are
unordered meaning that, when possible, the sequences shown in FIGS.
5, 6, and 7 can be performed in any convenient or desirable
order.
[0068] FIG. 5 is a flow diagram illustrating a method 50 for
storing data on a disk drive using network coding in a manner that
supports coded seeking in accordance with an embodiment. The method
50 may be implemented in connection with, for example, an operating
system, a disk drive controller, or some other processor or
controller associated with a data storage device, system, or
network. In some embodiments, the acts associated with method 50
may be carried out using multiple processors and/or controllers
operating together. A file that is to be stored on a disk drive may
first be received or identified (block 52). The file may be divided
into a plurality of equal-width block windows B.sub.l that each
have r data blocks (block 54). For each of the block windows, a
number of innovative coded blocks may be generated using network
coding techniques (block 56, 58). Each of the coded blocks may
include a linear combination of the corresponding r data blocks
that are made using random coefficients so that the coded blocks
are linearly independent of one another. In general, r or more
coded blocks may be generated for each block window. The coded
blocks generated for each block window may then be stored on the
disk drive (block 60). This process may be repeated until all of
the block windows of the original file have been processed and
stored (block 62, 64). Other or modified techniques for writing
coded data onto a disk drive in support of coded seeking may
alternatively be used. For example, in one such approach, a file
may be simply be divided into r data blocks without first forming
blocks windows. The r data blocks may then be used to generated
coded blocks for storage.
[0069] FIG. 6 is a flow diagram illustrating a method 70 for use in
retrieving data from a disk drive using coding seeking in
accordance with an embodiment. The method 70 may be implemented in
connection with, for example, an operating system, a disk drive
controller, or some other processor or controller associated with a
data storage device, system, or network. In some embodiments, the
acts associated with method 50 may be carried out using multiple
processors and/or controllers operating together. A read request is
first received that requests an innovative coded data block (or
degree-of-freedom) associated with a plurality of native data
blocks (block 72). The plurality of native data blocks may include,
for example, a plurality of blocks associated with a particular
block window of a data file or some other group of native data
blocks. An innovative coded data block that is associated with the
plurality of native data blocks is next selected that is closest to
a present position of a read head of the disk drive (block 74). The
innovative coded data block may be selected from a group of such
coded blocks that are known to be associated with the plurality of
native data blocks. The disk drive may then cause a read element to
move to the location of the selected coded data block and read the
coded block (block 76). This process may be repeated for each new
read request that is received for an innovative coded data block
associated with the plurality of native data blocks. In some
implementations, coded data blocks associated with the plurality of
native data blocks that were recently read during a common data
read process (e.g., during a read operation for a particular file)
are ignored during the selection process so that the coded data
block retrieved from the drive in response to the current read
request is linearly independent of previously retrieved coded
blocks.
[0070] FIG. 7 is a flow diagram illustrating a method 80 for use in
retrieving data from a disk drive that supports coding seeking in
accordance with an embodiment. The method 80 may be performed in
connection with, for example, an operating system of a computing
system that uses the disk drive to store data in a non-volatile
form or some other processor or controller associated with the disk
drive. It is first determined that a group of native data blocks
needs to be retrieved from the disk drive (block 82). In some
implementations, the group of native data blocks may represent a
block window associated with a data file stored on the data storage
device, although other groups of data blocks may alternatively be
used. In some embodiments, only a single data block within the
group of data blocks may be of interest, but the entire block will
need to be retrieved and decoded to have access to the desired
block. A read request may next be sent to the disk drive requesting
that an innovative coded block (or degree of freedom) associated
with the group of data blocks be read (block 84). The coded block
read from the disk drive in response to the request is subsequently
received from the disk drive and temporarily stored in a memory
(block 86). It may next be determined whether enough innovative
coded blocks (or degrees-of-freedom) have been retrieved from the
disk drive to extract the group of native data blocks from the
coded blocks (block 88). If not (block 88-N), another read request
may be sent to the disk drive requesting that an innovative coded
block associated with the group of data blocks (block 84) and the
process is repeated. This process may continue until a sufficient
number of innovative coded blocks have been retrieved to enable
decoding (block 88-Y). At this point, the innovative coded blocks
may be decoded (block 90). In some implementations, this may
comprise a full decoding operation that uses all of the retrieved
coded blocks. In implementations where progressive decoding is
used, this may comprise perform a last step of a decoding
process.
[0071] Although described above in the context of a magnetic hard
disk drive, it should be appreciated that many of the features
described herein may be used in connection with other data storage
devices that include one or more moving parts including, for
example, other disk based stored devices (e.g., CDROMs, DVDs,
BluRay.RTM. discs, etc.).
[0072] Having described exemplary embodiments of the invention, it
will now become apparent to one of ordinary skill in the art that
other embodiments incorporating their concepts may also be used.
The embodiments contained herein should not be limited to disclosed
embodiments but rather should be limited only by the spirit and
scope of the appended claims. All publications and references cited
herein are expressly incorporated herein by reference in their
entirety.
* * * * *