Data processing: database and file management or data structures – Database design – Data structure types
Reexamination Certificate
2002-03-26
2004-12-21
Pardo, Thuy N. (Department: 2175)
Data processing: database and file management or data structures
Database design
Data structure types
C707S793000, C707S793000, C707S793000, C707S793000, C379S028000, C379S029100, C709S241000
Reexamination Certificate
active
06834281
ABSTRACT:
BACKGROUND OF THE INVENTION
FIG. 1
illustrates a data processing system having nodes
12
a
-
12
c
coupled to a storage area network (SAN). The SAN includes a data storage system
20
coupled to nodes
12
a
-
12
c
via a SAN communication link
24
. Lastly, nodes
12
a
-
12
c
are coupled to each other via local area network (LAN) communication link
26
.
Nodes
12
a
-
12
c
may take form in any one of a number of different types of computer systems. For purposes of explanation, node
12
a
will take form in a server computer system. Nodes
12
b
and
12
c
are clients to node
12
a
Nodes
12
b
and
12
c
, however, may be servers for other functions.
As shown in
FIG. 1
, node
12
executes an operating system that includes a file system module and a file system driver filter module
30
a
. Nodes
12
b
and
12
c
also execute operating systems. The operating systems of nodes
12
b
and
2
c
do not include file system modules. The operating system executing on nodes
12
b
and
12
c
include file system driver filter modules
30
b
and
30
c
, respectively. Filters
30
a
-
30
c
are capable of communicating with each other via LAN communication link
26
.
File system
30
performs many functions. For example, file system allocates blocks or regions of memory in data storage system
20
in which data of files are stored. File system
30
also creates and maintains file meta data in lookup table (LUT)
34
a
. The meta data includes information which maps a file name to one or more blocks of memory in storage system
20
which contain data of the file.
Node
12
a
controls access to data storage system
20
. As noted above, nodes
12
b
and
12
c
can access files contained within the data storage system
20
. For example, application program
36
b
generates a request to access a file F in data storage system
20
. In the prior art, this request is intercepted by the file system driver filter
32
b
. In response to receiving the request to access file F, file system driver filter
32
b
access lookup table
34
b
to determine whether lookup table
34
b
maps F to meta data needed for accessing the one or more blocks in memory of storage system
20
which contains file F data. If lookup table
34
b
contains valid meta data for file F, then file F in data storage system
20
is accessed according to the meta data, and information thereof is provided to application
36
b
via node
12
b.
If, however, LUT
34
b
does not include valid meta data for file F, file system driver filter
32
b
generates a request for valid meta data. This request is transmitted to node
12
a
via LAN communication link
26
. File system driver filter
32
a
of node
12
a
receives the request for meta data, and in response, file system driver filter
32
a
accesses LUT
34
a
to determine whether a valid copy of file F meta data is contained therein. If a valid copy is found, then file system driver filter
32
a
transmits a response back to file system driver filter
32
b
via LAN communication link
36
. This response includes a valid copy of meta data for file F. File system driver
32
b
, in turn, stores the received meta data into LUT
34
B. Once file system driver filter
32
b
receives the valid meta data for file F, the request to access file F, generated by application
36
b
, can be fulfilled.
As noted above, node
12
a
is capable of accessing files in data storage system
20
. For example, application
36
a
may generate a request to modify (e.g., delete) data contained in file F or file F in its entirety. This request is intercepted by file system driver filter
32
a
. As noted above, file system
30
manages the allocation of memory in data storage system
20
for files stored therein. This management includes reallocation of memory blocks for files in response to, for example, a request to delete the file generated by application
36
a
. File system
30
, in response to receiving the request to delete a file via file system driver filter
32
a
, accesses LUT
34
a
with the filename and modifies the meta data thereof when the file is, for example, deleted from the storage system
20
.
One of the problems with the prior art is that a modification of meta data in LUT
34
a
by file system
30
can result in erroneous access of data by, for example, application
36
b
. More particularly, should file F stored in system
20
be deleted or perhaps truncated, file system
30
will update the meta data for file F stored in LUT
34
a
in accordance thereto. However, LUT
34
b
in node
12
b
contains what it believes is a valid copy of the meta data for file F which was provided by filter
32
a
upon a previous request for the meta data. Clearly, the meta data in LUT
34
a
is different from the meta data in LUT
34
b
. Subsequently, if application
36
b
generates a new request to read file F after the meta data in LUT
34
a
has been modified, the read request may result in accessing erroneous data because of the difference in file F meta data contained in LUTS
34
a
and
34
B.
To avoid this situation, when file system driver filter
32
a
receives a request to access a file from application
36
a
which will result in a change in the meta data that identifies the one or more memory blocks that contain the file data, file system driver filter
32
a
transmits instructions to file system driver filter
32
b
and file system driver filter
32
c
, via LAN communication link
26
, to invalidate meta data for file F stored in LUTs
34
b
and
34
c
. File system driver filters
32
b
and
32
c
invalidate the meta data for file F in LUTs
34
b
and
34
c
if nodes
12
b
and
12
c
are not currently accessing file F. If file F is currently being accessed via nodes
12
b
and/or
12
c
, then file system driver filters
32
b
and
32
c
will delay the invalidation of the meta data for file F until the access is complete.
Once file system drivers
32
b
and
32
c
invalidate the meta data for file F contained in LUTs
34
b
and
34
c
, file system drivers
32
b
and
32
c
transmit a message back to file system driver filter
32
a
, via LAN communication link
26
, indicating that file F is not being accessed by nodes
12
b
or
12
c
and that nodes
12
b
and
12
c
have invalidated meta data for file F stored therein. In response, the request to delete file F generated by
36
a
is subsequently transmitted by file system driver filter
32
a
to file system
30
. File F is depleted from storage
20
, and the meta data for file F is updated in LUT
34
a.
The system for maintaining the integrity of meta data for files in nodes
12
b
and
12
c
works well so long as file system driver filter
32
a
receives notification that meta data for a particular file will be changed in LUT
24
a
before the meta data therein changes. A problem arises when file system
30
directly receives (rather than indirectly receiving via the file system driver filter
32
a
) an access request which, when fulfilled, results in a modification of meta data that maps a file to one or more memory blocks. For example, file system
30
may receive an input/output (IO) control call to defragment data storage system
20
. This call is not received via filter
32
a
. File system
30
may also self initiate (i.e., without an externally received call) the storage defragmentation process. File system defragmentation of system
20
, whether self initiated or initiated in response to an externally received call, when completed may result in a modification in meta data that maps the file to one or more memory blocks.
At any rate, because certain access requests (e.g., I/O call for defragmentation) which do not first pass through file system driver filter
32
a
and, when completed, result in a modification of meta data in LUT
34
a
by file system
30
, LUTs
34
b
and
34
c
may unknowingly store invalid meta data. Requests to access files using invalid meta data will result in a return of erroneous data
SUMMARY OF THE INVENTION
Disclosed is a method for supporting coherent multi-node access to file system data. The method can be emp
Campbell Stephenson Ascolese LLP
Pardo Thuy N.
Veritas Operating Corporation
LandOfFree
Method and apparatus to support multi-node direct access to... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Method and apparatus to support multi-node direct access to..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method and apparatus to support multi-node direct access to... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3329514