[ale] FENRIS (nwfs) Source Code Now Available. (fwd)

[Chris Ricker]

I'm back from vacation and getting caught up on email.  On linux-kernel,
there was this message I thought those of you who still use Netware might be
interested in....

later,
chris

-- 
Chris Ricker                                               kaboom at gatech.edu
                                              chris.ricker at genetics.utah.edu

---------- Forwarded message ----------
Date: Fri, 18 Jun 1999 12:29:32 -0600
 From: Jeff Merkey <jmerkey at timpanogas.com>
Subject: FENRIS (nwfs) Source Code Now Available.

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 at timpanogas.com.  You
can report bugs to this email as well as to linux-kernel at vger.rutgers.edu.





- ------=_NextPart_000_010E_01BEB986.378C7260--


Please read the FAQ at http://www.tux.org/lkml/