Leaked source code of windows server 2003
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

190 lines
7.4 KiB

  1. What is the structure of a transaction ID. This is generated by the client
  2. (or transaction manager) and is passed through to the disk by Lfs.
  3. Can't store the next Lsn in a log record header because its exact location
  4. may not be known when a log record is being written (in-memory) or a
  5. page block is being written to disk. This is because the write to disk
  6. may occur before the next log record is received and there is no way to
  7. know if it will fit in the remaining part of the file or will wrap and
  8. be written to the beginning of the file.
  9. Log records that require multi-page allocation blocks will begin at the
  10. beginning of a page block. Then the fields which describe the data shift
  11. can be in a page header record and not a log record header.
  12. We restrict the data size of a log record to 32 bits.
  13. Log record types: We have an enumerated type for all log record, not
  14. a main type and subtypes. i.e. all commit protocol records are defined
  15. at the top level.
  16. Multi-page blocks: Page headers indicate whether they are the first
  17. or last page. During Lfs restart these pages may be walked through.
  18. As far as the analysis algorithm goes, these can be thought of as a
  19. single unit. All page(s) must be found or this will be considered
  20. a bad page(s), the next page then must be read to discover if this is
  21. a fatal error or the point where the system crashed.
  22. Looking up multipage via Lsn: Given Lsn pin appropriate page and look
  23. at log record. If single page then done. Otherwise, unpin page and
  24. pin multiple pages.
  25. For what operations do we need to check the update sequence array in
  26. the page headers.
  27. Log file header prior to restart areas. This will be a single system page
  28. and contain the log file base values which will allow both copies of the
  29. restart area to be found. This information will be duplicated in the restart
  30. areas so that if the sector containing the file header goes bad, an
  31. intelligent choice can be made for where to search for the first Lfs
  32. restart area. (Or we could duplicate it in the first x sectors).
  33. Should we checksum the log file header.
  34. Added client Id to the log record header.
  35. Is it reasonable to use a USHORT to index into the client array and a USHORT
  36. for the client sequence number.
  37. Do we even need a sequence number. Will the index number be sufficient to
  38. walk forward through the log records. When will the index be reused, only
  39. when a client closes his loghandle. In that case it will be impossible to
  40. start searching from an out of date Lsn.
  41. Change InitializeReadContext to LfsContextReadFirst and return the first Lsn.
  42. Read Next is LfsContextReadNext.
  43. May not need the LfsPreviousLsn in the log record header.
  44. Log record enumeration. Walking forwards, client will probably run
  45. out unexpectedly.
  46. Log record enumeration. Walking backwards, take Lsn, determine Log page
  47. boundary. Pin log page, if multiple pages unpin and repin multiple pages.
  48. Walking backwards, how likely are we to want to stay in the same log
  49. page for several records.
  50. Enumerating. It is possible we are pinning pages for read and may be trying
  51. to write them at the same time.
  52. If we have a page pinned multiple times, will that prevent it from being
  53. flushed with a ccflush call.
  54. Will a client want to look at several log records at once, or only one
  55. at a time. The current interface supports only one at a time.
  56. LOG CONTEXT BLOCK
  57. No synchronization of access to the log context block. Client
  58. shares the block at his own risk.
  59. How to resolve that enumeration may pin (for a while) a block of
  60. pages that are trying to be flushed.
  61. Enumeration (in the forward direction) may be trying to read a lsn
  62. as it is being written. Solution, write the log record before updating
  63. the last Lsn in the page header.
  64. This may make the LastLsn number in the context block obsolete as it
  65. may be outdated. However, any later Lsn's wouldn't have existed when
  66. the client started this call. Should we hide all new log records
  67. from him.
  68. Log file. How big may it be (ULONG, LARGE_INT)
  69. Log buffer control block. Access via global spinlock. Sets up frame for
  70. next write and then releases it. Count is kept in block of active writers,
  71. can't be flushed until active count is zero. Does this make sense, how
  72. do we wait until active count is zero.
  73. Lsn should be 96 bits. 64 bit file offset and 32 bit sequence value.
  74. The interface with the Lfs provides that the address of this structure
  75. be passed.
  76. Is it expensive to allocate and deallocate an event each time a new buffer
  77. is used.
  78. Can the restart areas offset safely be a ULONG.
  79. How can log service initiate a sector revectoring.
  80. Start log file sequence number at 1, then 0 indicates we have just wrapped.
  81. Since write operations to the log file must be serialized, there is no
  82. reason not to let the worker thread perform all the writes.
  83. Operations:
  84. Given an Lsn:
  85. Find the next Lsn
  86. Find the previous client Lsn
  87. Find the client undo next lsn.
  88. Given a log record.
  89. Find the client owner of the record
  90. Find the transaction ID for the record
  91. Log context blocks
  92. Allocate and deallocate
  93. Write into the fields.
  94. Determine if the next/prev Lsn resides in the same block of pages.
  95. Pin and unpin pages in the log file.
  96. Allocate and deallocate the user's buffer.
  97. Synchronize access to the context block (is this needed)
  98. Log client area
  99. Allocate and deallocate
  100. Verify the client as valid.
  101. Log buffer control blocks
  102. Allocate and deallocate
  103. Link into control block list for a particular log file.
  104. Allocate and deallocate buffer associated with control block.
  105. Determine the size required for the buffer.
  106. Determine where buffer fits in log file.
  107. Determine where the next log record should be in the buffer.
  108. Determine when all the authorized writes to the file have completed.
  109. Syncronize access to the fields of the contol block.
  110. Find the last Lsn for the page block.
  111. Determine when the flush operation to the log file has completed.
  112. Determine if the flush operation to the file was successful.
  113. Determine if the next log record fits in this buffer.
  114. Determine if user thread can be used to write log pages to the log file
  115. Log file control block.
  116. Allocate/Deallocate structure.
  117. Link log file control blocks to global record
  118. Know whether the sequence number has wrapped.
  119. Modify the fields of the structure.
  120. Write a restart area to the disk.
  121. Change the current restart area.
  122. Log data area
  123. Allocate and Deallocate structure
  124. Sychronize access to the fields.
  125. Add and remove fields from the workque.
  126. We need a structure to use for a log file information block.
  127. July 1,
  128. How do we store the update sequence stride on disk to read on a different
  129. system??
  130. What do we do when there is an I/O error writing to the disk?? How does
  131. an operation know that a previous I/O error has occurred??
  132. Do multiple clients open the same log file with the same file object or
  133. the same file?? (We could always check if the context pointers match)
  134. How do we disable the update sequence mechanics in order to originally
  135. recognize the log file.