Date: Thu, 31 Oct 1996 14:27:14 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: sextonr.crestvie@squared.com (Sexton Robert) Cc: pgiffuni@fps.biblos.unal.edu.co, freebsd-hackers@freefall.freebsd.org Subject: Re: SCO Filesystem Message-ID: <199610312127.OAA26259@phaeton.artisoft.com> In-Reply-To: <01FFD25B0187397C@mg01a.mhs.squared.com> from "Sexton, Robert" at Oct 31, 96 02:47:30 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> It depends on which SCO filesystem you mean. They support the older SysV > filesystem, with 1k and 2k blocks, but they introduced the Acer > Filesystem a few releases ago. I think its a SysV filesystem with > enhancements to the block layout techniques, as well as support for long > filenames and symlinks. As for as a I know, its proprietary. I don't > recall ever seeing a technical description of the design in print. I talked to the author of the "ACER Fast File System" at the 1989 SCO Developers conference (I first met SEF at the 1988). The Acer Fast file system is identical to the previous implementation, except that it uses a bitmap for allocation to reduce the amount of I/O required. There are a couple of cosmetic changes on top of that, but nothing as fundamental as the bitmap. This is a pretty trivial (and obvious) change to make, especially if you have a developement kit for an Acer FFS system release of an SCO OS, since the header files include macros for allocation bitmap decoding. > Things get worse, because they introduced two new filesystems in the new > release, the DTFS (Desktop filesystem), which includes compression, and > HTFS (High Throughput). One of these includes journaling, I forget > which. Once again, I'd be suprised if they weren't proprietary. These are FS's which were advertised by a third party in Unix Review and UNIX World as "add-ons". The compressing FS is also pretty trivial; it's not even true block compression. The "High throuput" FS has a lot of interesting optimizations, most of which are discoverable using block profiling. HTFS has a number of frightening race windows, which journalling doesn't quite save it from. When I was at Novell, we considered both of these for a source base to use in implementing the NetWare eXtended File System (NXFS), an attributed UNIX FS containing NetWare attributes, AppleTalk attributes, and OS/2 extended attributes and Mac Resource forks. We went with FFS (UFS) in the end (I was principle engineer for the thing). There is nothing "magical" about these implementations, except our VFS interface is still pretty poorly suited to adding new FS's without a lot of work to get around layering problems, a lot of code which has to be duplicated per FS which belongs in upper layers, and a full kernel recompile because the vfs_init still gets its side from the UFS vnops and vfsops structures intead of from a sizeof() in vnode_if.c. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199610312127.OAA26259>