Transactional file system for realizing atomic update of plural files by transactions

• US 7,349,927 B2
• Filed: 07/01/2004
• Issued: 03/25/2008
• Est. Priority Date: 09/29/1999
• Status: Expired due to Fees

• Current Assignee: Kabushiki Kaisha Toshiba (Toshiba Corporation)
• Original Assignee: Kabushiki Kaisha Toshiba (Toshiba Corporation)
• Inventors: Torii, Osamu, Yano, Hirokuni, Kanai, Tatsunori, Maeda, Seiji, Yao, Hiroshi, Kizu, Toshiki
• Primary Examiner(s): MAHMOUDI, HASSAN
• Application Number:
  US10/880,446
• Publication Number:
  US 20040236793A1
• Time in Patent Office: 1,363 Days
• Field of Search: 707/200, 707/201
• US Class Current: 1/1
• CPC Class Codes: G06F 11/1471 involving logging of persistent data for recovery
• CPC Class Codes: G06F 16/1865 Transactional file systems
• CPC Class Codes: G06F 9/466 Transaction processing
• CPC Class Codes: Y10S 707/99943 Generating database or data structure, e.g. via user interface
• CPC Class Codes: Y10S 707/99952 Coherency, e.g. same view to multiple users
• CPC Class Codes: Y10S 707/99953 Recoverability

Abstract

A transactional file system configured to realize atomic update of plural files by transactions. In the transactional file system, a log entry containing information for validating all updates made by a transaction collectively on a stable memory device, is generated for one or more files updated on a buffer region by the transaction since a start of a processing of the transaction until a commit of the transaction. Then, the log entry is written into the stable memory device at a time of the commit of the transaction.

Claims

1. A transactional file management method, comprising:

(a) generating a log entry containing an information for validating all updates made by a transaction collectively on a stable memory device, for a plurality of files updated on a buffer region by the transaction since a start of a processing of the transaction until a commit of the transaction,

wherein the step (a) generates the log entry by embedding in the log entry an information by which, whether the log entry has been written into the stable memory device completely or not, can be checked; and

(b) writing the log entry into the stable memory device at a time of the commit of the transaction such that the plurality of files updated by the transaction can be reflected on a file system in an atomic manner at a time of the commit and updates made before an abort can be cancelled at a time of the abort.

2. The transactional file management method of claim 1, wherein the step (a) generates the log entry that contains a meta information and a content information for all of the one or more files updated by the transaction.

3. The transactional file management method of claim 1, further comprising the step of:

writing a part or a whole of a content information of the one or more files updated by the transaction into the stable memory device before the commit of the transaction;

wherein the step (a) generates the log entry that contains a meta information for all of the one or more files updated by the transaction and any part of the content information that is still not written into the stable memory device.

4. The transactional file management method of claim 1, further comprising the step of:

invalidating all the updates made by the transaction collectively when the log entry read out from the stable memory device after an occurrence of fault indicates that the log entry has been written incompletely.

5. The transactional file management method of claim 1, wherein the step (b) writes the log entry into the stable memory device by embedding a position information on the stable memory device for writing a next log entry corresponding to another transaction to be committed next, into the log entry.

6. The transactional file management method of claim 1, wherein the step (a) generates a unified log entry for updates made by a plurality of transactions when a plurality of transactions are collectively committed.

7. The transactional file management method of claim 6, wherein the step (a) generates the log entry such that, when two or more transactions are updating an identical file on the buffer region, the log entry contains only an update content of the identical file by one transaction that is committed last among the two or more transactions.

8. A transactional file management method, comprising:

(a) generating a log entry containing an information for validating all updates made by a transaction collectively on a stable memory device, for one or more files updated on a buffer region by the transaction from a start of a processing of the transaction until a commit of the transaction; and

(b) writing the log entry into the stable memory device at a time of the commit of the transaction,

wherein the step (a) generates the log entry by embedding in the log entry an information by which whether the log entry has been written into the stable memory device completely or not can be checked, and

wherein the step (b) writes the log entry into the stable memory device by dividing the log entry into segments of a constant size.

9. The transactional file management method of claim 8, wherein the step (a) generates the log entry that contains a meta information and a content information for all of the one or mare files updated by the transaction.

10. The transactional file management method of claim 8, further comprising the step of:

writing a part or a whole of a content information of the one or more files updated by the transaction into the stable memory device before the commit of the transaction;

wherein the step (a) generates the log entry that contains a meta information for all of the one or more files undated by the transaction and any part of the content information that is still not written into the stable memory device.

11. The transactional file management method of claim 8, wherein the step (b) writes the log entry into the stable memory device by embedding a position information on the stable memory device for writing a next log entry corresponding to another transaction to be committed next, into the log entry.

12. The transactional file management method of claim 8, wherein the step (a) generates a unified log entry for updates made by a plurality of transactions when a plurality of transactions are collectively committed.

13. A transactional file system for managing files stored in a stable memory device and providing the files to processing by transactions, comprising:

a log entry generation unit configured to generate a log entry containing an information for validating all updates made by a transaction collectively on a stable memory device, for a plurality of files updated on a buffer region by the transaction since a start of a processing of the transaction until a commit of the transaction, and configured to generate the log entry by embedding in the log entry an information by which, whether the log entry has been written into the stable memory device completely or not, can be checked; and

a log entry writing unit configured to write the log entry into the stable memory device at a time of the commit of the transaction such that the plurality of files updated by the transaction can be reflected on a file system in an atomic manner at a time of the commit and updates made before an abort can be cancelled at a time of the abort.

14. A computer usable medium having computer readable program codes embodied therein for causing a computer to function as a transactional file system for managing files stored in a stable memory device and providing the files to processing by transactions, the computer readable program codes include:

a first computer readable program code for causing said computer to generate a log entry containing an information for validating all updates made by a transaction collectively on a stable memory device, for a plurality of files updated on a buffer region by the transaction since a start of a processing of the transaction until a commit of the transaction, and for generating the log entry by embedding in the log entry an information by which, whether the log entry has been written into the stable memory device completely or not, can be checked; and

a second computer readable program code for causing said computer to write the log entry into the stable memory device at a time of the commit of the transaction such that the plurality of files updated by the transaction can be reflected on a file system in an atomic manner at a time of the commit and updates made before an abort can be cancelled at a time of the abort.