Browse Prior Art Database

Maintaining Data Consistency in a Distributed Data Processing System

IP.com Disclosure Number: IPCOM000122416D
Original Publication Date: 1991-Dec-01
Included in the Prior Art Database: 2005-Apr-04
Document File: 4 page(s) / 112K

Publishing Venue

IBM

Related People

Chang, A: AUTHOR [+4]

Abstract

The following described methodology is useful in a distributed data processing system having multiple clients and a server.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 52% of the total text.

Maintaining Data Consistency in a Distributed Data Processing System

      The following described methodology is useful in a
distributed data processing system having multiple clients and a
server.

      Clients' cache file data and modifications to this data are not
written synchronously to the server.  If either the client or server
crashes while the client has modifications which have not been
reported to the server, then these modifications will be lost.
Therefore, clients are expected to periodically send back to the
server copies of file data and attributes which they have modified
and not otherwise reported since the last periodic sync.

      A client which does not hold a file's write token may extend a
file. During the server's periodic sync of the file system, the
client updates the inode's file size to reflect any received
DS2_putbytes and server process stores. Holders of a file's token
(read or write) believe that they know the file's size, and this size
needs to be updated to reflect changes at the server.  This file size
synchronization is accomplished by client periodic sync.

      The following describes actions that are performed during
periodic file system sync at the client and server. The discussion
assumes that file system periodic synchronization is performed by a
kernel process and not by calls of sync(2) or cron(1).  Periodic sync
at a client pushes dirty data from the client to the server, a
subsequent periodic sync at the server writes the data to disk;
sync(2) is assumed to issue DS2_fsync for each modified file.

      A different client implementation could issue DS2_fsync for
each modified file during periodic sync.  This would give stronger
integrity at the expense of performance (more network messages).

      The following rules describe periodic_sync at a client which
has remote files open:
1.   A client with dirty pages uses DS2_putbytes to update the
server.
2.   A client with the write token sends DS2_sync_attr which carries
the file size, modify count, and access count. The reply returns the
file size.
3.   A client with the read token sends DS2_sync_attr which carries
the access count.  The reply returns the file size.

      The file's size returned in steps 2 and 3 above allows the
client'...