Source code of Windows XP (NT5)
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.

243 lines
9.5 KiB

  1. Here is a list of all NTFS design issues which have come up that effect the
  2. structure, along with current resolution (if there is one) of the issue. The
  3. resolution of these issues affects the "NTFS Design Specification 1.1" issued
  4. May 29, 1991. This list will be the final qualification to the spec until
  5. there is time to update it to a form which reflects the actual implementation.
  6. Of course the most precise definition of NTFS will always be in the header
  7. file which describes its structure: ntfs.h.
  8. These issues have been collected primarily from our own internal review and
  9. the feedback received from MarkZ. They are listed here in no particular
  10. order.
  11. Issue 1:
  12. Support for nontagged attributes is a pain in the low-level attribute
  13. routines, as well as in Format and ChkDsk. They are of very little
  14. value to the File System in terms of space or performance.
  15. Resolution:
  16. Nontagged attributes are being dropped for the purposes of NTFS's own
  17. use of attributes to implement the disk structure. Nontagged attributes
  18. will be supported with the general table support.
  19. Issue 2:
  20. The EXTERNAL_ATTRIBUTES attribute, should have a better name, and its
  21. definition should be changed to simplify various NTFS algorithms.
  22. Resolution:
  23. The attribute name has been changed to the ATTRIBUTE_LIST attribute.
  24. It is still only created when a file requires more than one file record
  25. segment. At that time it is created to list all attributes (including
  26. those in the base file record) by type code and (optional) name. it is
  27. ordered by Attribute Type Code and Attribute Name.
  28. One reason for this change is to facilitate the enumeration of all
  29. attributes for a file with multiple file record segments. This
  30. slightly different definition also gives NTFS's attribute placement
  31. policy more freedom to shuffle attributes around within the file
  32. record segments.
  33. Issue 3:
  34. Attribute ordering rules within the file, within each file record segment,
  35. and within the ATTRIBUTE_LIST were not completely specified.
  36. Resolution:
  37. The only rule for the ordering of attributes within each file, if there
  38. are multiple file record segments, is that STANDARD_INFORMATION must be
  39. in the base file record segment, and (at least the first part of) the
  40. ATTRIBUTE_LIST attribute must also be in the base file record segment.
  41. In general, the system should try to keep the other system-defined
  42. attributes with the lowest Attribute Type Codes present in the base file
  43. record segment when possible, for performance reasons.
  44. Within each file record segment, attributes will be ordered by type code,
  45. name, and then value. (If an attribute is not unique in type code and
  46. name, then it must be indexed and the value must be referenced.)
  47. The entries of the ATTRIBUTE_LIST will be ordered by attribute code and
  48. name.
  49. Reliance on these ordering rules may be used to speed up attribute lookup
  50. algorithms.
  51. Issue 4:
  52. NTFS is NOT secure on removeable media without data encryption.
  53. Resolution:
  54. Functionality for the encryption of communications and physical media
  55. is already planned for Product 2 of NT, at which time we will decide
  56. what the best mechanism will be for integrating this support with
  57. removeable NTFS volumes. We must insure now that this can be implemented
  58. in a upward-compatible manner.
  59. Issue 5:
  60. It would be very desirable for WINX to have the ability to uniquely
  61. identify and open files by a small number.
  62. Resolution:
  63. Logically the ability to use this functionality must be controlled by
  64. some privilege, as it is expensive and nearly impossible to come up with a
  65. consistent strategy on how to do correct path traversal checking, in a
  66. system such as NTFS which supports multiple directory links to a single
  67. file. Once the requirement for a special privilege is accepted, it is
  68. relatively easy for NTFS to support an API which would allow files to
  69. be opened by their (64-bit) File Reference number. The File Reference
  70. is perfect for this purpose, as it includes a 16-bit cyclically-reused
  71. sequence number to detect the attempt to use a stale File Reference.
  72. I.e., the original file with the same 48-bit Base File Record address has
  73. been deleted, and a new file has been created at the same address.)
  74. THIS REQUIRES A NEW NT I/O API.
  75. Issue 6:
  76. Enumeration of files in a directory in NT could be very slow, since
  77. to get more than just a file's name requires reading (at least) the
  78. base file record for the file.
  79. Resolution:
  80. The initial NT-based implementation of NTFS will come up with a
  81. strategy for clustering file record segments together in the MFT for
  82. files created in the same directory. Current thinking is that this
  83. will be done *without* change to the NTFS structure definition. So,
  84. for example, the first 128 files in a directory might be contiguous in
  85. the MFT, and then the second 128 will also be contiguous, etc. This
  86. will allow the implementation to prefetch files up to 128 file record
  87. segments at a time with a large spiral read, then expect cache hits during
  88. the enumeration.
  89. Secondly, at some point the implementation will cache enumeration
  90. information, to make subsequent enumeration of the same directory
  91. extremely fast.
  92. Issue 7:
  93. Is it an unnecessary complexity to NTFS to support multiple collating
  94. rules, as opposed to a simple byte-comparison collation? Note that
  95. frequently the caller collates himself anyway.
  96. Resolution:
  97. This is not resolved yet pending further discussion.
  98. The current reason NTFS plans to support multiple collating rules,
  99. is that collating in the caller can have bad performance and response
  100. characteristics in large directories. For example, consider a Windows
  101. App which requests the enumeration of a directory with 200 files (possibly
  102. over the network to a heavily loaded server), and it is going to
  103. display this enumeration in a List box with 10 or 20 lines. If it
  104. does not have to collate the enumeration, it can start displaying
  105. as soon as it receives part of the enumeration. Otherwise it has
  106. to wait to get the entire enumeration before it can collate and display
  107. anything.
  108. Issue 8:
  109. Should there be a bit in STANDARD_INFORMATION to indicate whether a
  110. file record has an INDEX attribute or not?
  111. Resolution:
  112. There is no plan to do this, unless we find additional reasons
  113. to do so that we are missing. Currently we see how this bit could
  114. speed the rejection of illegal path specifications, but it would
  115. not speed the acceptance of correct ones. Note that from the structure
  116. of NTFS, it is legal for a file to have both an INDEX attribute *and*,
  117. for example, a DATA attribute.
  118. Issue 9:
  119. The algorithms and consistency rules surrounding the 8.3 indices need to
  120. be clarified.
  121. Resolution:
  122. This will be done by 7/31.
  123. Issue 10:
  124. Why not eliminate the VERSION attribute and move it to
  125. STANDARD_INFORMATION?
  126. Resolution:
  127. We will do this, and then define an additional file attribute
  128. and/or field which controls whether or not versioning is enabled and
  129. possibly how many versions are allowed for a file.
  130. Issue 11:
  131. There should be a range of system-defined attribute codes which are
  132. not allowed to be duplicated, as this will speed up some of the
  133. lookup algorithms.
  134. Resolution:
  135. This will be done.
  136. Issue 12:
  137. Is duplication of the log file the correct way to add redundancy to
  138. NTFS to allow mounting in the event of read errors.
  139. Resolution:
  140. Upon further analysis, it was determined that the needed redundancy
  141. was incorrectly placed. It is more important to duplicate the first
  142. few entries of the MFT, than to duplicate the start of the log file.
  143. This change will be made.
  144. Issue 13:
  145. The spec describes how access to individual attribute types may be
  146. controlled by special ACEs, which is incompatible with the current
  147. NT APIs and our security strategy.
  148. Resolution:
  149. This will be fixed. Access to user-defined attributes will be controlled
  150. by the READ_ATTRIBUTES and WRITE_ATTRIBUTES access rights.
  151. Issue 14:
  152. A file attribute should be added which supports more efficient handling
  153. of temporary files.
  154. Resolution:
  155. An attribute will be added for files, and possibly directories, which
  156. will enable NTFS to communicate "temporary file" handling to the Cache
  157. Manager. Temporary files will never be set dirty in the Cache Manager
  158. or written to disk by the Lazy Writer, although the File Record will
  159. be correctly updated to keep the volume consistant. If a temporary file
  160. is deleted, then all writes to its data are eliminated. If MM discovers
  161. that memory is getting tight, it may choose to flush data to temporary
  162. files, so that it can free the pages. In this case the
  163. correct data for the file will eventually be faulted back in.
  164. This makes the performance of I/O to temporary files approach the
  165. performance of putting them on a RAM disk. An advantage over RAM disk,
  166. though, is that no one has to specify how much space should be used
  167. for this purpose.
  168. Issue 15:
  169. It would be nice to have some flag in each file record segment to say
  170. if it is in use or not. This would simplify chkdsk algorithms, although
  171. it would require the record to be written on deletion.
  172. Resolution:
  173. This will be done. It is difficult to suppress the write of the file
  174. record on deletion anyway.