|
From: Anton A. <ai...@ca...> - 2004-05-17 12:01:18
|
Ok, here goes how I envisage development of the NTFS driver to proceed.
Note that I am not taking into account that other people might contribute
/ work on specific features and submit them to me which could obviously
cause some feature(s) to be implemented in a different order to what the
roadmap specifies but this is how I, were no one to contribute, am likely
to proceed. Any contributions would be a bonus on top of this and are of
course both strongly encouraged and welcomed! (-:
Disclaimer: I reserve the right to turn the roadmap on its head or to
throw it away and do it completely differently but with some luck things
will happen roughly like this... (-;
First of all, here is the current status of the driver (current release
2.1.11/kernel 2.6.6-2.6.7):
- Basic read-only is complete:
this includes:
- access to normal files
- access to compressed files and directories
- loopback mounting of normal/compressed files
- NFS exporting of mounted volume (2.6 kernels only)
- hard links
but this does not include:
- access to encrypted files
- ACLs ($Secure)
- quota ($Quota)
- symlinks and DFS/HSM stuff ($Reparse)
- access to named streams
- access to extended attributes (EAs)
The above missing read-only features will be implemented but for me
personally they are very low priority. Obviously all of these missing
read-only features are also missing from the supported read-write features
and they are going to be implemented only after their read-only
counterparts are implemented.
Another feature, this one is read-write, that is missing is journalling.
This is not planned until everything else is implemented. At the moment,
the only journalling related feature that is implemented is that the
journal is checked at read-write (re)mount time and if it is obviously
clean the mount is allowed and if we cannot detemine that the journal is
clean the mount is aborted or forced into a read-only mount depending on
the mount option "on_errors".
- Basic non-truncating/non-extending file-overwrite is partially complete:
this includes:
- writing to non-resident normal files (no changes in file size)
but this does not include:
- writing to resident normal files (no changes in file size)
- writing to compressed files
- Other write features that are not implemented yet at all:
- changes in file size
- creating files/directories
- deleting files/directories
- creating hard links
- creating sym links
- removing sym links
Now that we are all up to speed on where we are at with the driver, here
is the roadmap itself:
- Implement writing to resident normal files (no changes in file size).
This has already been done once in the ntfs-2.5-devel tree but it at least
used to contain a deadlock so I need to merge that code into the current
driver (ntfs-2.6 tree) while taking care not to take over the deadlock...
This involves implementing the ability to:
- dirty and then to write dirty mft records to disk and the ability to
- mark inodes dirty and to write them out on request.
Note, the above has already been implemented once but it contains a
deadlock so the code must be carefully lifted and analysed and only
applied piecemeal to the driver to ensure the deadlock doesn't get taken
over.
- Implement setting the volume dirty bit in the volume flags on read-write
(re)mount and clear it again on clean umount. That way a crash would
cause chkdsk to be run on the volume when Windows mounts it and hopefully
this would correct any problems/inconsistencies.
- Implement atime updates.
- Implement changes in file size:
- make normal files smaller (easy). This requires ability to:
- deallocate clusters
- resize attributes to make them smaller
- convert non-resident attributes to resident ones
- make normal files larger (not so easy). This requires ability to:
- allocate clusters
- resize attributes to make them bigger
- convert resident attributes to non-resident ones
Note the above will not support attribute list attributes so files that
containthis (e.g. highly fragmented files) will not be able to have their
size changed.
- Write support for attribute list attributes so that it is possible to
resize all normal files, including very fragmented ones. This requires
the ability to:
- work with the attribute list attribute, including:
- remove attribute list attribute entry
- modify attribute list attribute entry
- add attribute list attribute entry
- remove the attribute list attribute
- create the attribute list attribute
- deallocate mft records
- allocate mft records
- split attributes into extents, including:
- split run list into fragments
- size fragments appropriately for the available space
- compress run list fragments into mapping pair arrays
- coalesce attribute extents
- Write support for compressed files. (This might well end up moving
up ro down the list as I consider it more of a "cool" feature than a
high priority item. It may well even drop to the second "low priority"
list...)
- Support for file/directory deletion (includes hard link removal). This
requires the ability to:
- remove entries from the index root and allocation attributes
- deallocate index allocation blocks
- truncate index allocation attribute and bitmap attribute
- removal of index allocation attribute and bitmap attribure
- Support for file/directory creation. This requires the ability to:
- add entries to the index root and allocation attributes
- allocate index allocation blocks
- extend index allocation attribute and bitmap attribute
- create index allocation attribute and bitmap attribute
- Support creating hard links.
- Support rename.
At this point we have complete basic read-write support and can start
implementing the more fancy features (i.e. the ones I described above as
being very low priority for me). At present the likely order of me
implementing these features is something like (high-level only, no
details):
- create and remove symbolic links ($Reparse)
- special files (character and block devices, sockets, etc...)
- ACLs ($Secure, including user specified mapping of UNIX ids to SIDs)
- Quota ($Quota)
- Named streams
- Extended attributes
- Encrypted files (requires user supplied private keys)
- DFS/HSM stuff ($Reparse)
- User space journalling ($UsnJrnl)
- Meta data journalling ($LogFile)
I don't think I have missed any featues but if I have then either apply
common sense as to where I am likely to fit them in or ask me...
Best regards,
Anton
--
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer / IRC: #ntfs on irc.freenode.net
WWW: http://linux-ntfs.sf.net/ & http://www-stu.christs.cam.ac.uk/~aia21/
|
