Neil Webber. Operating System Support for Portable Filesystem Extensions. In Proceedings of the 1993 USENIX Winter Conference, pages 219--228, January 1993.  Home/Search   Document Not in Database   Summary   Related Articles   Check

....implemented by Rosenthal (in SunOS 4.1) around 1990[15] A few other works followed Rosenthal, such as further prototypes for extensible file systems in SunOS[18] and the Ficus layered file system[4, 7] at UCLA. Webber implemented file system interface extensions that allow user level file servers[20]. Unfortunately this work required modifications to existing file systems and could not perform as well as in kernel file systems. Several newer operating systems offer a stackable file system interface. They have the potential of easy development of file systems offering a wide range of ....

N. Webber. Operating System Support for Portable Filesystem Extensions. USENIX Conf. Proc., pages 219--25, Winter 1993.

....first implemented stacking in SunOS 4. 1 in the early 1990s[15] A few other works followed his, such as further prototypes for extensible file systems in SunOS[19] and the Ficus layered file system[3, 5] Webber implemented file system interface extensions that allow user level file servers[21]. Unfortunately, these implementations required modifications to either existing file systems or the rest of the kernel, limiting their portability significantly, and affecting the performance of native file systems. FiST achieves portability using a minimal stackable base file system, Basefs, ....

N. Webber. Operating System Support for Portable Filesystem Extensions. USENIX Conf. Proc., pages 219--25, 1993.

....the all a file. We also compared the performance of uuencodefs to user level uuencode utilities. We found the performance savings to be comparable to those with gzipfs compared to GNU zip. 5 Related Work Most work in the area of stackable or extensible file systems appeared in the early 1990s[10, 12, 25, 27, 28]. Newer operating systems, such as the HURD[3] and Plan 9[22] have an extensible file system interface. Some of these works suggested the idea of stackable compression file systems. Two additional works in Spring[15, 18] and Ficus[11] discussed a similar idea for implementing a stackable ....

N. Webber. Operating System Support for Portable Filesystem Extensions. USENIX Conf. Proc., pages 219--25, Winter 1993.

....Instead, each agent is provided with a symmetric system call interface allowing the layering of agents. Thus, clients continue to see the same unextended system call interface. In this system, agent(s) are attached to specific clients and are apparently not shared. The File Monitor Interface [49] provides a userlevel server facility that responds to vnode calls intercepted inside the operating system. The intercept mechanism is similar to the Frigate Dispatcher and can selectively intercept calls based on special file attributes. However, there is no provision for an object oriented ....

N. Webber. Operating System Support for Portable Filesystem Extensions. In Proceedings of the Winter 1993 USENIX Conference, pages 219--228. USENIX Association, Jan. 1993.

....first implemented stacking in SunOS 4. 1 in the early 1990s[19] A few other projects followed his, including further prototypes for extensible file systems in SunOS[22] and the Ficus layered file system[5, 7] Webber implemented file system interface extensions that allow user level file servers[25]. Unfortunately, these implementations required modifications to either existing file systems or the rest of the kernel, limiting their portability significantly, and affecting the performance of native file systems. FiST achieves portability using a minimal stackable base file system, Basefs, ....

N. Webber. Operating System Support for Portable Filesystem Extensions. USENIX Conf. Proc., pages 219--25, Winter 1993.

....vnode interface [30, 39] is a prime example of this approach. While this interface is extremely useful for adding complete new file systems, it does not support the incremental addition of new functionality. Implementation details of the interface also vary widely across operating system vendors [51]. Applying this technique to make existing operating systems more extensible would require substantially modifying and exposing all interfaces where additionalfunctionality is desired, effectively re engineering the majority of the operating system. We take the alternative approach of adding ....

Neil Webber. Operating System Support for Portable Filesystem Extensions. In Proceedings of the 1993 USENIX Winter Conference, pages 219--228, January 1993.

....the bulk of the overhead can be attributed to the inefficiency in the virtual memory system. Similar problems were noted in the OSF 1 kernel, whose high kernel miss overhead impacted the design of GMS [15] 6. 3 Portability The vnode layers of different operating systems are considerably different [52]. One needs arcane knowledge of the kernel internals in order to port a file system to a different vnode layer. This is one of the major obstacles to deploying xFS on a variety of different platforms. For a cluster file system such as xFS, a portable operating system interface not only would allow ....

....operating system interface not only would allow us to more easily take full advantage of the resources in a heterogeneous cluster, but it would also reduce the system complexity. To this end, the vnode interfaces have failed miserably. Despite many years of research in extensible file systems [39, 5, 40, 38, 42, 22, 1, 28, 52], the construction of portable file systems has remained a difficult undertaking, especially for the commercial operating systems. We are currently investigating portable and efficient interposition agents as a means of distributing our code [17] In this section, we have seen that the vnode layer ....

Webber, N. Operating System Support for Portable Filesystem Extensions. In Proceedings of the 1993 USENIX Winter Conference (January 1993), pp. 219--228.

....concept. In reality, there are a number of VFS interfaces, since most manufacturers have chosen to make their own extensions from the base VFS developed by Sun. In addition, since the manufacturers are the primary clients of VFS, the VFS API and implementation tend to change subtly without notice[Web93] And, since not all manufacturers support dynamic linking of kernel modules it is sometimes necessary to specially configure and statically link new file system support into the kernel. An alternative option is extend the Unix namespace via servers implementing the NFS protocol. Using the NFS ....

Neil Webber. Operating system support for portable filesystem extensions. In Proceedings of the Winter 1993 USENIX Conference, pages 219--228, San Diego, California, January 25-29, 1993. Usenix Association.

....File Organizer (UFO) system [AIS97] is another example of using debugging facilities. UFO intercepts system calls and redirects them by using the UNIX proc facility. There are also some systems that intercept file system calls within the operating system. The File Monitor Interface (FMI) [Web93] provides a user level server facility based on the VFS interface. Vnode operations are either passed to the standard VFS based file system or to a server. Information in special file attributes is used to determine if server redirection occurs. In this way, the intercept mechanism is similar to ....

Neil Webber. "Operating System Support for Portable Filesystem Extensions. " In Proceedings of the Winter 1993 USENIX Conference, pp. 219--228. USENIX Association, January 1993.

....not only would allow us to more easily take full advantage of the resources in a heterogeneous cluster, but it would also reduce the system complexity. To this end, the vnode interfaces have failed miserably. Since the construction of a portable vnode layer has been a difficult undertaking [39], we are currently investigating portable and efficient interposition agents as a means of distributing our code [14] In this section, we have seen that the vnode layer has achieved the goal of making xFS available to unmodified applications at a considerable cost. Some of the disadvantages are ....

Webber, N. Operating System Support for Portable Filesystem Extensions. In Proceedings of the 1993 USENIX Winter Conference (January 1993), pp. 219-- 228.

....these modifications. The tradeoff is that making kernel modifications requires an understanding of an existing kernel a large and complex system containing hundreds of thousands of lines of code. Kernel modifications are often not portable between successive releases of the same operating system [45], and not at all between different operating systems. In addition, operating system kernels typically lack state of the art debugging and development tools, hindering development. Finally, understanding and modifying operating system kernels is a time intensive task 1 . Building a middleware ....

Neil Webber. Operating System Support for Portable Filesystem Extensions. In Proceedings of the 1993 USENIX Winter Conference, pages 219--228, January 1993.

.... load balancing and process migration) Unfortunately, Modifying an existing kernel considerably impacts system portability: not only are kernel modifications not portable across platforms, but kernel modifications are often not even valid across different releases of the same operating system [35]. In 1993, the primary operating systems available for state of the art architectures were commercial products. Modifying a commercial operating system limits the ability to distribute the resulting system. Further, the time required to obtain source, learn, modify, and debug a commercial kernel ....

Neil Webber. Operating System Support for Portable Filesystem Extensions. In Proceedings of the 1993 USENIX Winter Conference, pages 219--228, January 1993.

....One solution taken to this problem is to standardize internal kernel interfaces, for example, the vnode layer [Kleiman 1986] In principle this could make porting extensions to new platforms much easier, but in practice this has not happened. First, no two platforms share the same vnode interface [Webber 1993]. In fact, many operating systems do not even provide source or binary compatibility to the vnode interface across successive releases. Second, these interfaces This work was supported in part by the Defense Advanced Research Projects Agency (N00600 93 C 2481, F30602 95C 0014) the National ....

....share the same vnode interface. Even successive releases of the same operating system often do not provide source or binary compatibility to the vnode interface. Furthermore, vnode interfaces often do not capture all of the relevant information needed by the new file system implementation [Webber 1993]. Consequently, installing a new file system using the vnode interface often requires access to kernel sources as well as a fair amount of non portable code. WebFS [Vahdat et al. 1996] provides a global file system using the HTTP protocol. This file system provides cache coherent and authenticated ....

N. Webber. "Operating System Support for Portable Filesystem Extensions". In Proceedings of the 1993 USENIX Winter Conference, pp. 219--228, January 1993.

....them when necessary. 3.5 Compatibility with Layers The flexibility stacking provides promotes rapid interface and layer evolution. Unfortunately, rapid change often rapidly results in incompatibility. Interface change and incompatibility today often prevent the use of existing filing abstractions [15]. A goal of our design is to provide approaches to cope with interface change in a binary only environment. File system interface evolution takes a number of forms. Third parties wish to extend interfaces to provide new services. Operating system vendors must change interfaces to evolve the ....

....command identifies the existing stack layer and where the new layer should be attached into the filing name space. 4.2 Extensibility in the UCLA Interface Accommodation of interface evolution is a critical problem with existing interfaces. Incompatible change and the lock step release problem [15] are serious concerns of developers today. The ability to add to the set of filing services without disrupting existing practices is a requirement of diverse third party filing development and would greatly ease vendor evolution of existing systems. The vnode interface allows that the association ....

Neil Webber. Operating system support for portable filesystem extensions. In USENIX Conference Proceedings, pages 219--228. USENIX, January 1993.

....to forward every file system operation to user level, so typically new file system implementations are added directly into the kernel. The Andrew file system is largely implemented at user level, but it maintains a kernel cache for performance [HKM 88] Epoch s tertiary storage file system [Web93] is one example of operating system kernel code developed by a third party vendor. Another example is user programmable high performance I O systems. If data is arriving on an I O channel at a high enough rate, performance will be degraded substantially if control has to be transferred to user ....

Neil Webber. Operating System Support for Portable Filesystem Extensions. In Proceedings of the 1993 Winter USENIX Conference, January 1993.

No context found.

Neil Webber. Operating System Support for Portable Filesystem Extensions. In Proceedings of the 1993 USENIX Winter Conference, pages 219--228, January 1993.

No context found.

Webber, N., "Operating Systems Support for Portable Filesystem Extensions," Proceedings of the Winter 1993 Usenix Conference, January 1993.

Online articles have much greater impact   More about CiteSeer.IST   Add search form to your site   Submit documents   Feedback  

CiteSeer.IST - Copyright Penn State and NEC