From: "Jeff Merkey" <jmerkey@timpanogas.com> To: <linux-kernel@vger.rutgers.edu>, <linux-kernel-announce@vger.rutgers.edu> Subject: FENRIS (nwfs) Source Code Now Available. Date: Fri, 18 Jun 1999 12:29:32 -0600 This is a multi-part message in MIME format. ------=_NextPart_000_010E_01BEB986.378C7260 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Linux Gods, The FENRIS (nwfs) source code for linux is now available for ftp at 207.109.151.240. We apologize for being some 17 days late with this first release. Novell raised some legal issues (threatened litigation). We achieved resolution with Novell Wednesday this week. we are pleased that Novell has chosen to support our efforts to provide this technology to the Linux Community (since they figured out they had no valid case with us, and really and truly wanted to find a way to get along with us moving forward). We applaud Novell's decision to take the high road in their relatiionship with TRG. Attached are the release notes for this version. The version is downloadable from either ww.timpanogas.com or ftp from 207.109.151.240. Jeff Merkey P.S. FEED THE WOLF ------=_NextPart_000_010E_01BEB986.378C7260 Content-Type: application/octet-stream; name="NOTES" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="NOTES" RELEASE NOTES FOR NWFS-1.4.1 This is the first public release of the FENRIS (nwfs) file system for linux. We will be posting a new release every couple of days over the next few months. We anticipate that there will in fact be dozens of releases. We will annotate bugs and capabilities added and fixed as these releases are rolled out. To make this release, type: make -f nwfs.mak clean make -f nwfs.mak See the Docs on our ftp site for instructions on mounting and loading volumes. There are several important things to note about this release. 1. No attempt has been made to tightly couple and optimize this first release with the linux buffer cache. ext2, fat, and several other linux file systems are very incestuous with the ll_rw_block function. nwfs has attempted to stick to the published interfaces into the buffer cache. as one would expect, the performance is not a high as it could be by tightly coupling nwfs into the buffer cache. this is a future optimization that will show up over the next several weeks. One noteworthy question to ask would be why linux file systems have to get incestuous with the buffer cache to scale well. 2. The SMP locking in nwfs relies heavily on sleep locks rather than spin locks. this is to help folks out there who are testing this first release for logic and file system compatibility issues. attempting to provide any useful information from a crashed system that is deadlocked with spin locks is almost impossible. it is hoped that the use of sleep locks will make it easier for folks to track down bugs and report them. we will replace most of the sleep locks with spin locks later this month in a separate release. the heavy use of sleep locks does degrade performance but also allows full parallelism for SMP testing for those folks who will test this on SMP systems. 3. The GNU compiler is a broken piece of SHIT!!!! no offense, but it has a lot of problems aligning structures and packing them properly, even when told to do so. The result of this problem is that the NFS namespace on linux will get corrupted if we attempt to write Unix style permissions into this namespace. I am looking into this problem, and attempting to determine a good workaround. For now the ability to create symbolic links, hard links, and device files under nwfs is disabled (although the code and functions are present to do this, they are stubbed out). 4. DOS name mangling at present gives Netware some hickups when you attempt to mount the volumes back under netware. Netware vrepair will fixup the names. The name mangling function being used by the FAT file system is incompatible with what Netware expects. We are continuing our analysis of Netware DOS names and are working on this problem. Most names come out ok, but once and a while, a name get's transformed into something that Netware doesn't really like. 5. Rename and Shadow functions are being reworked (we found a fix for some of the GNU compiler problems). These functions will be included in a release next week (most probably Monday 6/20/99). We will be posting two releases a week to our ftp server for the next couple of weeks. 6. We are implementing something very similar to TurboFATs in Netware with nwfs. We are calling them RapidFATs and their implementation is SMP and somewhat different from NetWare to avoid possible infringement issues. As such, it is possible to read and write suballocation elements on a netware volume with nwfs, however, we have disabled the ability to allocate suballocation elements for the volume until the RapidFAT subsystem is completed. We anticipate completion and testing of this feature by end of next week. Novell has been very gracious in allowing us to release this code to the public, however, they have asked that we avoid any areas that may infringe on their patents. As such, we are implementing suballocation management using an alternative method that is just as performant as native netware. 7. RapidFAT will increase the performance of reads and writes on nwfs mounted volumes 2-3 times (and in some cases log2n times) over the current implementation. RapidFats require stateful FCB (file control block) elements to be created during open in order to build direct FAT indexing tables that are shared by all requestors to a file. Netware achieves it's horrific speed by using TurboFats and in memory name hashing for searching. Our current directory searching method is not so good because linux doesn't provide a good way to store and pass hints between the file system and user space. The legacy Netware file system has strong dependencies on user/fs interaction and the ability to pass these hints. We are implementing an extensible has to overcome the limitations of the design of the linux VFS so we can achieve the performance of native netware file systems. We anticipate release of the extensible hashing cccode for the parent hash end of next week along with RapidFATs. 8. Approximately 18,000 lines of Windows NT specific code were removed from this implementation, however, there are stil some remnants of code form the Windows NT version of nwfs that will remain in the linux release. perhaps the most interesting ones can be found in NWFILE.C. NT file systems are far more advanced than Linux. NT places the VM Cache on top of the file system rather than beneath it. The advantages to this model are all performance related. If you change any nwfs Linux code, you must also change the Windows NT code as well if it is affected by your changes or I will reject your code submissions. 9. The Directory Block LRU has been disabled as the Linux Buffer cache seems to provide "good enough" performance without it. The Native Netware file sysem is heavily dependent on having it's own directory block LRU for high speed searches, creates, deletes, etc. If it makes sense down the road, we may put this back in. 10. The Shadow function will be in by Monday. This function will make it possible to perform slavage operations on nwfs and recover deleted files. right now, we act just like Linux -- when you delete something, then it's really gone. The salvage utility for Linux for salvaging deleted files will be out sometime in July of this year. Please submit changes or corrections to jmerkey@timpanogas.com. You can report bugs to this email as well as to linux-kernel@vger.rutgers.edu. ------=_NextPart_000_010E_01BEB986.378C7260-- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/