Matt Benjamin wrote: > Jeff, > > I recall seeting the IFS working (by some definition of "working") on > Eric JW's workstation in 2005. What specifically are the missing > features that must be implemented to complete the work? > > Matt
Matt:
(1) the current code works on pre-Vista 32-bit platforms. In
order to support 64-bit and Vista there needs to be a more
generalized abstraction framework implemented. One of the
reasons the OSR File System Framework was so desirable to
me was to provide this abstraction. Unfortunately, the OSR
FSF is not freely redistributable and I can't justify requiring
each individual that wants to build OpenAFS to spend $95,000
for a license. Therefore, we will have to build our own
abstraction framework in order to enable us to support new OS
versions without major re-writes in the future.
(2) lack of a Network Provider interface required to interface with
the Windows MUP component. This is necessary for accessing
AFS via UNC paths instead of a hard coded drive letter among
other things.
(3) the current communication mechanism is inefficient
(4) metadata handling is not currently implemented
(5) the data handling is non-optimal. currently data is cached
in openafs client service. there is no attempt to manage
Windows' caching of file data within the kernel. copying
data from the user mode service to the kernel so it can be
copied back to user mode for application usage is expensive.
(6) OpLock protocol support in the Network Provider must be implemented
(7) Conversion of the user mode service into a TDI client on pre-Vista
systems would be nice.
(8) Once this work is completed, OpenAFS will have to build a separate
kernel module for each supported platform and bundle them all into
the installers with only the appropriate kernel module being
installed on the machine.
(9) There is also quite a bit of OpenAFS Cache Manager work that needs
to be done to handle Unicode file names, etc.
Jeffrey Altman
smime.p7s
Description: S/MIME Cryptographic Signature
