1. Introduction
   1.1. Project/Component Working Name:

		Storage Infrastructure: File System Interfaces (FSI)

   1.2. Name of Document Author/Supplier:

		Rich B

   1.3. Date of This Document:

		10/24/01

   1.4. Name of Major Document Customer(s)/Consumer(s):
	1.4.1. The Steering Committees you expect to review your project

		SOESC
	        ONSC

	1.4.2. The ARC(s) you expect to review your project

		PSARC

	1.4.3. The Director/VP who is "Sponsoring" this project

		John L

	1.4.4. The name of your business unit

		Software Systems

2. Project Summary
   2.1. Project Description

	The File System Interfaces project will deliver published
	interfaces that enable Sun and third party filesystem vendors
	to better maintain and build filesystems. 

	Versioning the interfaces will allow unbundled filesystems to be
	decoupled from specific Solaris releases.  Virtual memory (VM)
	interfaces will also be reworked to minimize the dependency
	between filesystem and VM implementations.

	The major components of this project include: 
	- Identification/stabilization of exported and internal filesystem
	  interfaces 
	- Identification/stabilization of kernel services used by filesystems
	- A mechanism to provide interface versioning 
	- A guide to writing filesystems in Solaris using these interfaces
	- Improved filesystem and VM interaction  (Separate sub-project:
	  20010321_steve.m)

   2.2. Risks and Assumptions

	There is a risk that these changes may destabilize some of
	the existing file systems.  We will include a mechanism that
	provides compatibility with the existing interfaces for those
	cases where the risk of destabilization is too great.

3. Business Summary
   3.1. Problem Area

	Unbundled filesystems have had to deliver in lockstep
	with Solaris releases.  Often third-party unbundled
	filesystems are not ready by FCS.  This is partially
	due to changes in the interfaces that filesystems use.
	Since the interfaces are undocumented, this compounds
	the problem since there is no vehicle to inform developers
	of new changes.

	New filesystem development is hampered by the fact
	that none of our filesystem interfaces are documented
	except by the source code. Documenting (and stabilizing)
	the interfaces used by filesystems would encourage new
	filesystem development outside of Sun as well as ease the
	development of new filesystems within Sun.  Additionally,
	this will assist third party developers with maintenance
	and porting efforts.

	This project aims to solve both of these problems by
	stabilizing the filesystem interfaces, providing an
	interface versioning mechanism, providing interfaces
	to common data structures (vnode, vfs), and documenting
	all of the interfaces that filesystems use.

   3.2. Market/Requester

	Third-party filesystem developers (e.g., Veritas)
	Internal filesystem developers (including NFSv4)

   3.3. Business Justification

	In order to help encourage new filesystem development, we
	need to document the interfaces that filesystems use.

	Documented interfaces are a prerequisite to encouraging
	new filesystem development in Solaris.  It encourages
	innovation in the industry (as an example, ReiserFS on
	Linux) and makes it easier to develop filesystems
	internally.

	Stable, versioned interfaces make it easier for unbundled
	filesystem products to be available when a new release of
	Solaris becomes available.  The prime examples are the
	Veritas storage products (VxVM/VxFS).  One of the reasons
	customers resist moving to a new release of Solaris is that
	these products are often not available at FCS.

   3.4. Competitive Analysis

	Many of our competitors have better documented filesystems
	interfaces.  The two main examples are _xxx_ and _xxx_,
	but even Linux could be considered to have a better documented
	filesystem interface since the most current source and design
	documentation is freely available.  Many Solaris filesystems
	developers are forced to read the Solaris source code just so
	they can understand our interfaces.

	Well documented filesystem interfaces open the door to innovation
	in the storage area for Solaris. For example, several independent
	filesystem projects (e.g., ReiserFS) are being developed under
	Linux.

   3.5. Opportunity Window/Exposure

	This is long overdue. Much of this work described here has
	been discussed in various filesystem strategy forums in
	the early to mid 1990's.

   3.6. How will you know when you are done?

	This project can be considered done when:

	- NFSv4 has been successfully ported to the FSI.  (Other
	  existing Solaris file systems are being assessed for
	  the risk vs. reward of porting to the FSI.)

	- The system passes the appropriate standard conformance
	  tests at least to the level that the system does before
	  integrating these changes.

	- The system successfully passes the tests provided by the
	  development team.


4. Technical Description

	The interfaces that filesystems use can be separated into
	four categories: External interfaces (e.g.,VOPs, VFSOPs),
	common filesystem routines (e.g., dnlc routines), virtual
	memory interfaces (e.g., page_*, pvn_*), and kernel service
	routines (e.g., kmem_cache*, _insque, _remque).  The major
	tasks to be performed to achieve the goals of this project
	are as follows:

	- Determine the set of interfaces necessary to develop
	  filesystems
	- Work with PSARC to formalize these interfaces and classify
	  them as "Evolving" (similar to the DDI/DKI).
	- Publish a guide on the use of those interfaces

	NOTE:  Because the interaction between filesystems and
	virtual memory (VM) require more than simply formalizing the
	VM interfaces, the VM work is a separate sub-project.  See
	20010321_steve.mcpolin for further details.

	Some of the interfaces have been identified as candidates
	for the DDI/DKI.  The team is working with the Solaris I/O
	team to determine the most effective way to handle those
	interfaces.

	Since innovation in the filesystem area will surely require
	modification to these interfaces over time, a set of rules
	and/or mechanisms to version interfaces will be proposed.
	Also, common data structures such as vnodes will be made
	opaque to filesystems where practical.  This will make it
	possible for filesystems to be decoupled from Solaris
	releases.  Of course, performance needs will need to be
	considered to achieve the right balance.


5. Reference Documents

	Storage Infrastructure (formerly File System Infrastructure)
	Architectural Specification:
	Storage Infrastructure Virtual Memory Component:

6. Resources and Schedule
   6.1. Projected Availability

	Q2FY03 (Availability of some components in Q4FY02)

   6.2. Cost of Effort

	Approximately 3.5 staff years

   6.3. Cost of Capital Resources

	Using existing capital infrastructure

	6.4.6. Notes/Dependencies:

		NFSv4 is expecting to use these interfaces in Solaris 10

	6.4.7. Target RTI Date/Release:

		The target release for the entire project is Solaris 10
		but will likely be broken up into several RTIs.  The
		first of the RTIs are expected to be submitted in 4/2002.

	6.4.8. Target Code Design Review Date

		2/2002

   6.5. ARC review type: Standard

7. Prototype Availability
   7.1. Prototype Availability

	1/2002

   7.2. Prototype Cost

	12 staff-weeks