Ruggedized block device driver

• US 6,668,336 B2
• Filed: 03/29/2002
• Issued: 12/23/2003
• Est. Priority Date: 11/08/2001
• Status: Expired due to Term

• Current Assignee: Western Digital Israel Limited (Western Digital Corporation)
• Original Assignee: M-Systems Flash Disk Pioneers Ltd. (Western Digital Corporation)
• Inventors: Lasser, Menahem
• Primary Examiner(s): Beausoliel, Robert
• Assistant Examiner(s): Bonzo, Bryce P.
• Application Number:
  US10/108,410
• Publication Number:
  US 20030088804A1
• Time in Patent Office: 634 Days
• Field of Search: 714/5, 714/15, 711/161, 711/162, 707/202, 707/204
• US Class Current: 714/5.11
• CPC Class Codes: G06F 11/1435 using file system or storage system metadata
• CPC Class Codes: G06F 11/1474 in transactions G06F16/20 takes precedence
• CPC Class Codes: G06F 2201/815 Virtual middleware or OS functionality using virtual machines to implement generic software techniques for error detection or fault masking G06F11/1484
• CPC Class Codes: G06F 2201/82 Solving problems relating to consistency ensuring consistency in mirrored systems G06F11/2064

Abstract

A ruggedized file system, which provides ruggedness to non-volatile storage media at the device driver level. The ruggedized block device driver implementation provides ruggedness at the device driver level, thereby allowing atomic sequences of operations by the file system. Accordingly, the device driver is told that the current data state is a “fall-back” consistent state, into which the system should wake up if interrupted prior to completion of the sequence, following which operations are executed as required by the file system, including erasing, writing or overwriting blocks. The device driver is further told when the atomic sequence is complete, such that a new consistent state is thereby defined. It is, accordingly, the responsibility of the device driver to ensure that either the sequence completes and the file system reaches the target consistent state, or if power is lost or any other failure occurs in the middle, the file system will wake up in the initial fallback state. Except for activating this “atomicity” feature as described above, the file system does not have to be aware of any implementation detail of the ruggedness solution.

Claims

1. A method for writing or otherwise changing data in a non-volatile storage device supported by a block device driver so as to provide ruggedized or multitasking-ruggedized operation, the method comprising the steps of:

a. sending a command to the device driver for defining the start of a transaction;

b. sending a sequence of one or more commands which are part of said transaction to the device driver, each command potentially changing the data contents of the device; and

c. sending a command to the device driver for defining the end of said transaction.

2. The method of claim 1, wherein if a failure occurs after step (a) but before step (c), the device driver rolls back the effects of all said commands issued in step (b) and returns the storage device to contain said data contents as before step (a).

3. The method claim 1 in which the device driver identifies data associated with said commands associated with said transaction, by associating a transaction field with each physical block, such that all data of said transaction is in blocks whose transaction fields are set.

4. The method of claim 3 in which closing a transaction is achieved by clearing said transaction fields associated with said physical blocks associated with said commands associated with said transaction.

5. The method of claim 1, in which ruggedness or multitasking-ruggedness capability of the device driver can be instructed to be turned on or off.

6. The method of claim 1, in which said non-volatile storage device is a unit-based non-volatile storage device.

7. The method of claim 1, wherein upon receiving a reading command said block device driver returns the most recently written version of the requested data which is not associated with an open transaction.

8. The method of claim 1, wherein upon receiving a reading command said block device driver returns the most recently written version of the requested data regardless if said recently written version of the requested data is associated with an open transaction.

9. The method of claim 1, wherein upon receiving a reading command, said block device driver returns data selected from the group consisting of the most recently written version of the requested data which is not associated with an open transaction, and the most recently written version of the requested data regardless if it is associated with an open transaction, and wherein said block device driver enables said driver'"'"'s caller to determine said selection.

10. The method of claim 1, wherein said command defining the end of a transaction further comprises setting a flag in said non-volatile storage device to mark “

closing is in progress”

for said transaction.

11. A method for writing or otherwise changing data in a non-volatile storage device supported by a block device driver so as to provide ruggedized or multitasking-ruggedized operation, the method comprising the steps of:

a. sending a command to the device driver for defining the start of a transaction, and getting from the device driver a transaction handle associated with said transaction;

b. sending a sequence of one or more commands to the device driver, each command made part of said transaction by associating it with said transaction handle, and each command potentially changing the data contents of the device; and

c. sending a command to the device driver for defining the end of said transaction.

12. The method of claim 11, wherein multiple transactions can be open at the same time.

13. The method of claim 12, wherein a block can be written by a first transaction even if it was previously written by a second transaction that is still open at the time of writing by said first transaction.

14. The method of claim 11, wherein if a failure occurs after step (a) but before step (c), the device driver rolls back the effects of all said commands issued in step (b) and returns the storage device to contain said data contents as before step (a).

15. The method of claim 12, wherein if a failure occurs while multiple transactions are after step (a) but before step (c), the device driver rolls back the effects of all said commands issued in step (b) of all said transactions and returns the storage device to contain said data contents as before step (a) of all said transactions.

16. The method of claim 11 in which the device driver identifies data associated with said commands associated with said transaction, by associating a transaction handle with each physical block, such that all data of said transaction is in blocks whose transaction handle equals the transaction handle associated with said transaction.

17. The method of claim 16, in which closing a transaction is achieved by nullifying said transaction handles associated with said physical blocks associated with said commands associated with said transaction.

18. The method of claim 11, in which ruggedness or multitasking-ruggedness capability of the device driver can be instructed to be turned on or off.

19. The method of claim 11, in which the driver can at any time accept commands which are not associated with any transaction, even if one or more transactions are open, and even if said commands change the data contents of said device.

20. The method of claim 11, in which said non-volatile storage device is a unit-based non-volatile storage device.

21. The method of claim 11, wherein upon receiving a reading command said block device driver returns the most recently written version of the requested data which is not associated with an open transaction.

22. The method of claim 11, wherein upon receiving a reading command said block device driver returns the most recently written version of the requested data regardless if said recently written version of the requested data is associated with an open transaction.

23. The method of claim 11, wherein upon receiving a reading command, said block device driver returns data selected from the group consisting of the most recently written version of the requested data which is not associated with an open transaction, and the most recently written version of the requested data regardless if it is associated with an open transaction, and wherein said block device driver enables said driver'"'"'s caller to determine said selection.

24. The method of claim 11, wherein said command defining the end of a transaction further comprises setting a flag in said non-volatile storage device to mark “

closing is in progress”

for said transaction.

25. A method for enabling a file system to write or otherwise change data in a non-volatile storage device supported by a ruggedized or multitasking-ruggedized block device driver, so as to provide ruggedized or multitasking-ruggedized operation of the file system, the method comprising the steps of:

a. examining each command received by said file system, for determining whether said command should be protected from failures; and

b. for each said command determined to be protected from failures;

i. sending a command to said device driver for starting a transaction;

ii. performing said command received by said file system according to algorithms of said file system, generating at least one command to said device driver, said at least one command potentially changing the data contents of said device; and

iii. sending a command to the device driver for ending said transaction.

26. The method of claim 25, in which said ruggedized or multitasking-ruggedized operation of said file system can be instructed to be turned on or off.

27. A method for enabling a file system to write or otherwise change data in a non-volatile storage device supported by a ruggedized or multitasking-ruggedized block device driver, so as to provide ruggedized or multitasking-ruggedized operation of the file system, the method comprising the steps of:

a. examining each command received by said file system, for determining whether said command should be protected from failures; and

b. for each said command determined to be protected from failures;

i. sending a command to said device driver for starting a transaction, and getting from the device driver a transaction handle associated with said transaction;

ii. performing said command received by said file system according to algorithms of said file system, generating at least one command to said device driver, said at least one command potentially changing the data contents of said device, and making said at least one command part of said transaction by associating it with said transaction handle; and

iii. sending a command to the device driver for ending said transaction.

28. The method of claim 27, in which said ruggedized or multitasking-ruggedized operation of said file system can be instructed to be turned on or off.

29. A method for converting an existing non-ruggedized file system on a non-volatile storage device supported by a ruggedized or multitasking-ruggedized block device driver, into a ruggedized or multitasking-ruggedized file system, the method comprising the steps of:

a. adding, in the beginning of the file system code implementing each file system command which might change data contents of the storage device, new code for sending a command to the device driver for starting a transaction; and

b. adding, at the end of the file system code implementing each file system command which might change said data contents of the storage device, new code for sending a command to the device driver for ending said transaction.

30. The method of claim 29 in which the resulting ruggedized or multitasking-ruggedized file system is compatible with said existing not ruggedized file system on the same physical device, such that either a physical device operated under said ruggedized or multitasking-ruggedized file system can be operated under said existing file system, or a physical device operated under said existing file system can be operated under said ruggedized or multitasking-ruggedized file system, without loss of data when changing between one file system and the other file system.

31. A method for converting an existing non-ruggedized file system on a non-volatile storage device supported by a ruggedized or multitasking-ruggedized block device driver, into a ruggedized or multitasking-ruggedized file system, the method comprising the steps of:

a. adding, in the beginning of the file system code implementing each file system command which might change data contents of the storage device, new code for sending a command to the device driver for starting a transaction and getting from the device driver a transaction handle associated with said transaction;

b. for each driver command within the file system code implementing each file system command which might change data contents of the storage device, where said driver command potentially changes the data contents of said device, making it part of said transaction by associating it with said transaction handle; and

c. adding, at the end of the file system code implementing each file system command which might change said data contents of the storage device, new code for sending a command to the device driver for ending said transaction.

32. The method of claim 31 in which the resulting ruggedized or multitasking-ruggedized file system is compatible with said existing not ruggedized file system on the same physical device, such that either a physical device operated under said ruggedized or multitasking-ruggedized file system can be operated under said existing file system, or a physical device operated under said existing file system can be operated under said ruggedized or multitasking-ruggedized file system, without loss of data when changing between one file system and the other file system.

33. A method for a software application to write or otherwise change data on a non-volatile storage device, where the storage device is supported by a ruggedized or multitasking-ruggedized block device driver and a file system, so as to provide ruggedized or multitasking-ruggedized operation of the application, the method comprising the steps of:

a. sending a command to the device driver for starting a transaction;

b. sending a sequence of at least one command to the file system, each said command potentially changing said data contents of the device; and

c. sending a command to the device driver for ending said transaction.

34. A method for converting an existing non-ruggedized application using a non-volatile storage device supported by a ruggedized or multitasking-ruggedized block device driver and a file system, into a ruggedized or multitasking-ruggedized application, the method comprising the steps of:

a. adding, before code sending any sequence of commands to the file system which might change the file system'"'"'s data contents, new code for sending a command to the device driver, which starts a transaction; and

b. adding, after said code sending any sequence of commands to the file system which might change the file system'"'"'s data contents, new code for sending a command to the device driver, which ends said transaction.

35. A system providing ruggedized or multitasking-ruggedized operation of a non-volatile storage device, comprising:

physical non-volatile storage media; and

a software block device driver which is ruggedized or multitasking-ruggedized by itself, independently of a file system or other software application using it, where said device driver supports the joining of driver calls into transactions.

36. The system of claim 35, in which multiple transactions can be open at the same time.

37. The system of claim 36, in which a block can be written by a first transaction even if it was previously written by a second transaction that is still open at the time of writing by said first transaction.

38. The system of claim 35, in which said physical non-volatile storage media is unit-based media.

39. The system of claim 35, in which said device driver identifies data associated with commands associated with said transaction, by associating a transaction field with each physical block, such that all data of said transaction is in blocks whose transaction fields are set.

40. The system of claim 35, in which said device driver identifies data associated with commands associated with said transaction, by associating a transaction handle with each physical block, such that all data of said transaction is in blocks whose transaction handle equals the transaction handle associated with said transaction.

41. The system of claim 35, in which ruggedness or multitasking-ruggedness capability of said ruggedized or multitasking-ruggedized device driver can be instructed to be turned on or off.

42. The system of claim 35, in which the driver can at any time accept commands which are not associated with any transaction, even if one or more transactions are open, and even if said commands change the data contents of said device.

43. The system of claim 35, wherein upon receiving a reading command said block device driver returns the most recently written version of the requested data which is not associated with an open transaction.

44. The system of claim 35, wherein upon receiving a reading command said block device driver returns the most recently written version of the requested data regardless if said recently written version of the requested data is associated with an open transaction.

45. The system of claim 35, wherein upon receiving a reading command, said block device driver returns data selected from the group consisting of the most recently written version of the requested data which is not associated with an open transaction, and the most recently written version of the requested data regardless if it is associated with an open transaction, and wherein said block device driver enables said driver'"'"'s caller to determine said selection.

46. A system providing ruggedized or multitasking-ruggedized operation of a file system on a non-volatile storage device, comprising the following:

a. physical non-volatile storage media;

b. a software block device driver for operating said storage media, said device driver being ruggedized or multitasking-ruggedized by itself, independently of the file system or other software applications using it, where said device driver supports the joining of driver calls into transactions; and

c. a ruggedized or multitasking-ruggedized file system wherein ruggedness or multitasking-ruggedness of said file system is achieved by using the ruggedized or multitasking-ruggedized features of said block device driver.

47. The system of claim 46, wherein said ruggedized or multitasking-ruggedized file system is compatible with at least one non-ruggedized file system on the same physical device, such that either a physical device operated under said ruggedized or multitasking-ruggedized file system can be operated under said non-ruggedized file system, or a physical device operated under said non-ruggedized file system can be operated under said ruggedized or multitasking ruggedized file system, without loss of data when changing from one file system to the other file system.

48. The system of claim 46, in which ruggedness or multitasking-ruggedness capability of said ruggedized or multitasking-ruggedized file system can be instructed to be turned on or off.

49. A system providing ruggedized or multitasking-ruggedized operation of a software application on a non-volatile storage device, comprising the following:

a. physical non-volatile storage media;

b. a software block device driver for operating said storage media, said device driver being ruggedized or multitasking-ruggedized by itself, independently of the file system or other software applications using it, where said device driver supports the joining of driver calls into transactions;

c. a file system; and

d. a software application, such that ruggedness or multitasking-ruggedness of said application is achieved by using the ruggedized or multitasking-ruggedized features of said block device driver.