What is the DAFS?
The Direct Access File System (DAFS) is a shared-file access protocol designed to take advantage of System Area Networks using the Virtual Interface (VI) architecture. The VI architecture provides a new, transport independent, memory-to-memory networking paradigm. It is designed for high-throughput, low-latency System Area Network or clustered environments. VI allows bulk data transfer directly to or from application buffers. VI also allows applications to access VI-capable hardware without operating system intervention. DAFS directly takes advantage of both these capabilities.

What network infrastructure does DAFS use?
DAFS uses VI as its underlying transport mechanism. VI can be implemented on a variety of network infrastructures. Currently there are several implementations of VI that use the VI over Fibre Channel draft standard, and several implementations that use proprietary interconnection networks. In the future, the Infiniband standard will support VI. A VI over TCP/IP is also expected, which will enable the use of gigabit and 10-gigabit Ethernet networks.

How does DAFS coordinate file sharing between systems?
DAFS is designed to allow high-speed, fault-tolerant, consistent views of files to a heterogeneous environment of servers that may be running different operating systems. The specification provides a consistent, cached locking mechanism that tolerates client or file server failures and failovers. DAFS also provides user authentication and cluster node access control for security.

How does DAFS differ from conventional network file access protocols?
Traditional shared-file systems rely on general-purpose network protocols and interface cards to provide applications with access to files. The network protocols break data up into small packets, with all the resulting overhead of packet assembly/disassembly done in software. The resulting data is then buffered in the operating system kernel to control flow, providing general-purpose access. Applications wishing to access this data must perform context switches to the operating system to access the network buffers.

DAFS, on the other hand, uses VI architecture to provide a high-performance solution to file sharing. Optimal data packet sizes are negotiated and assembled/disassembled in hardware. DAFS also bypasses kernel buffering and context switching by writing data directly into application memory space. The result is a fast, highly scalable improvement on traditional shared-file systems.

How does DAFS differ from conventional file systems with directly attached storage?
Traditional file systems that use directly attached storage are implemented inside operating system kernels and use kernel buffers to cache file system data. Application file requests must first make an operating system call and are satisfied by copying the data from the buffer cache to application buffers. In addition, sharing data with other machines requires complex proprietary software, and requires complex data management.

DAFS, on the other hand, provides direct application data transfer and implicit data sharing using an open protocol, and simplifies data management.

How will applications take advantage of DAFS?
DAFS will be implemented as a dynamically linkable library. The DAFS library will make use of a VI provider library by the vendor of the VI hardware. Applications can either make use of direct calls to the DAFS library using an OS-independent interface similar to normal OS I/O requests or use normal OS-dependent I/O calls through a transparent adaptation library.

How does DAFS improve system performance?
DAFS improves system performance by allowing applications to bypass operating system control, buffering, and heavy-duty network protocol operations that tend to bottleneck I/O throughput. Direct access I/O results in low-latency and low overhead data sharing, which increase system scalability and performance.

Who will benefit from using DAFS?
Any system that provides scalable application service can benefit from using DAFS. One example of such systems would be a set of diskless Web servers connected to one or more file servers that store Web information. Another example is a cluster of diskless servers running a highly available shared database that uses a file server to store database information.

DAFS is primarily designed for clustered, shared-file network environments, where a limited number of server-class clients connect to a set of file servers via a dedicated high-speed network. The sweet spot for DAFS is where these “client” systems are centrally located and managed, and able to take advantage of VI's fast data transfer semantics.

Can DAFS be used over a WAN or for general-purpose file sharing?
In order to meet high-performance criteria, DAFS is designed for high-throughput, low-latency networks connecting a limited number of client machines that are centrally managed and have a certain level of trust between systems. DAFS may be inappropriate for some wide-area, general-purpose file-sharing environments.

How does DAFS improve system scalability, availability, and manageability?
DAFS is designed to improve the efficiency and resiliency of shared file access in a clustered, System Area Network environment. Separating computing resources from storage resources allows each to be scaled and managed independently. Computing resources can be scaled by adding diskless commodity servers. Storage can be scaled either by adding more storage to existing file servers or by adding more file servers. Application servers see a common shared pool of storage. Availability improves because the architecture supports simple application server failover. File servers can be set up to failover also.

How does the DAFS specification process work?
The DAFS specification and a reference implementation will be passed on to a standards body (still to be named) for further refinement and industry approval. Additional information can be found at http://www.DAFScollaborative.org.

When will DAFS be available?
A reference implementation of DAFS should be available in late 2000. The first commercial implementations are expected in mid 2001 targeting the Sun Solaris®, Linux®, and Microsoft Windows® platforms, with others expected to follow.