From: "Jeff Merkey" <jmerkey@timpanogas.com> To: <linux-kernel@vger.rutgers.edu>, Subject: NwFs 1.4.5 Source Code Available (FENRIS) Date: Wed, 7 Jul 1999 16:20:09 -0600 This is a multi-part message in MIME format. ------=_NextPart_000_0162_01BEC894.955DF3B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Linux Folks, NwFs Release 1.4.5 is now available for download at ftp server 207.109.151.240. Please refer to the release notes regarding changes and updates made to this release. We are now using Bonnie to regression test and benchmark NwFs. As expected, the extremely heavy use of sleeplocks in NwFs does impact overall performance significantly, however, we will leave these locks in until the intial testing phase of our codebase has been completed. It is very difficult for users to provide any significant feedback about concurrency bugs when a system is deadlocked with spinlocks. We plan to replace the sleeplocks with fast mutexes and spin locks and of this month and after the initial regression testing is completed. We are being hammered with requests about the 2.2/2.3 version. We ask folks to be patient. We are rigorously testing each change now against Netware 3.x, 4.x, and 5.x, and against all available revisions of the Netware NFS server software for Netware 4 and Netware 5. When these tests are completed, we will release the 2.2/2.3 version. We will send out one more release of 2.0.37 which contains mirroring very soon. After this final 2.0.37 release, then we will be moving all of our releases to 2.2/2.3 Please feel free to respond with any comments, suggestions, or bug reports. Jeff Merkey CEO, TRG ------=_NextPart_000_0162_01BEC894.955DF3B0 Content-Type: application/octet-stream; name="NOTES" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="NOTES" RELEASE NOTES FOR NWFS-1.4.5. This release is specific to 2.0.37. 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. Notes. 1. This release corrects the "... empty subdirectory has no free blocks = ..." message that Netware 5.x spits out after mounting a volume that has been extensively written by NwFs. Netware expects at least one free 4K block of dir entries for each empty directory in a directory file (???). This seems broken to us, however, we replicate the Netware = Behavior to remain compatible with Netware. We have tested this rather = extensively, however, we have still seem some remote cases. This error is benign = under linux, however, Netware responds to it by attempting to free any empty directories on the volume to free up space in the directory file. There is a preset limit in Netware relative to how large the directory file is allowed to grow. When this problem occurs, we always have exceeded this size. 2. There were some nasty debug messages and cleanup unwind cases that were flushed out by the BONNIE test suite when a volume completely filled up. These messages were "Cluster Write Error [XXX]." There were also some issues with concurrency with the directory file. We are at present using a super block lock for directory create, though this isn't very parallel for SMP. We are replacing this lock with finer grained locks next release after we complete a good test run of BONNIE. 3. The Symbolic Link and Device File Functions now are implemented and have been thoroughly tested with Netware 4.x, 5.x and with the Netware for NFS Server that uses the Unix Name Space. As it turns out Netware implements symbolic links in an identical manner to Linux. Device files are also implemented identically with regard to file semantics. However, Netware NFS doesn't seem to know anything about FIFO (PIPE) = files under Linux, and will annotate permissions as "?--------" when = displaying these files. NOTE: You can only use Unix style permissions for device files, symbolic links, and hard links if the NFS namespace is present on a Netware volume. Also, if you mount the Netware NFS = Server after having used a Netware volume under Linux, then Netware NFS will change some of the file and directory permissions to match the Netware Trustee Access Model. 4. Hard Links have some dependencies on Netware NFS, and don't work correctly at present on Linux. This is due to the way Novell actually implemented hard links on Netware. Under Netware, there is a "Master" hardlink file and if you delete it, then it renders all of the hard links invalid. Linux under EXT2 does not appear to exhibit identical behavior, but rather appears to abstract the data stream from each inode entry, and if you delete the original file, then the data stream remains intact on all inodes. This may not be the "textbook" way of doing it, but what Linux has implemented seems better than what exists in Netware. As such, we are implementing hardlinks in the NFS namespace on a Netware volume so that if you delete the "Master" file, then we move the datastream to another file. Under Netware, the non-master hard links are simply directory entries that point in a chain to (PrevDirNo, EndDirNo, etc.) the master directory entry. This entry number chain is maintained in the NFS namespace. 5. We have been running NwFs against the BONNIE Test Suite, and it has passed all of the tests without incident. We are continuing our testing. Next release will attempt to fix the hard link architectural issues with the Netware file system, and implement FastFATs for full volume Suballocation support. 6. We apologize that we have not put mirroring up yet. We are still completing our BONNIE regression tests and compatibility testing with all of the available versions of the Netware NFS server on Netware 3.x 4.x, and 5.x. We will attempt to post the 2.2/2.3 version next week with all of these fixes also. Please let us know if there are additional bugs and report them to jmerkey@timpanogas.com or linux-kernel@vger.rutgers.edu. ------=_NextPart_000_0162_01BEC894.955DF3B0-- - 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/