NwFs 1.4.5 Source Code Available (FENRIS)

Jeff Merkey (jmerkey@timpanogas.com)
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/