From: "Jeff V. Merkey" <jmer...@timpanogas.com>
Subject: NWFS Open Source for 2.2 and 2.4 Releases 3/27/00
Date: 2000/03/25
Message-ID: <fa.e5sibhv.o0aqho@ifi.uio.no>#1/1
X-Deja-AN: 602017200
Original-Date: Fri, 24 Mar 2000 17:54:38 -0700
Sender: owner-linux-ker...@vger.rutgers.edu
Original-Message-ID: <38DC0E4E.27D2171D@timpanogas.com>
To: linux-ker...@vger.rutgers.edu, linux-kernel-annou...@vger.rutgers.edu
X-Accept-Language: en
Content-Type: multipart/mixed
X-Orcpt: rfc822;linux-kernel-outgoing-dig
Organization: TRG, Inc.
MIME-Version: 1.0
Newsgroups: fa.linux.kernel
X-Loop: majord...@vger.rutgers.edu

FOR IMMEDIATE RELEASE - US1

Timpanogas Research Group( Announces Release of the Open Source NWFS 2.2 
NetWare File System on Linux 2.2 and 2.4 Kernels, and the NWFS-64 Open Source 
File System for IA64 Linux.

Orem, Utah - March 27, 2000 -  Timpanogas Research Group, Inc. located in Orem, 
Utah is pleased to announce immediate availability of the NWFS 2.2 NetWare File 
System Open Source Code for Linux.  This release supports Linux Kernels 2.0, 
2.2, and 2.4.     

NWFS 2.2 is a Virtual File System (VFS) Implementation of Novell's Native 
NetWare File System for the Linux Platform. NWFS provides all the capabilities 
of Novell's existing legacy NetWare 3.x and 4.x file systems as well as NetWare 5. 
Included with the NWFS 2.2 Release for Linux is the source code for the file system 
driver.  Utilities that allow users to create and manage NetWare file systems, 
partitions, volumes and mirroring configurations are available via TRG's web site 
at www.timpanogas.com or FTP from 207.109.151.240. 

Additionally, NWFS 2.2 is the first Symmetrical Multi-processing (SMP) implementation 
of the Native NetWare File System, which allows users to take advantage of the 
superior performance of SMP machines and Linux. Other features of NWFS 2.2 include 
dynamic data redirection, hot-fixing, volume striping, multiple namespace support, 
suballocation, and volume mirroring.

TRG is also announcing the NWFS-64 Open Source NetWare File System for IA64 Linux.  
NWFS-64 is a 64-bit implementation of Novell's Native NetWare File System on the 
Linux Platform.  NWFS-64 for Linux Kernel 2.4 and above will be available Open Source 
from TRG's website at www.timpanogas.com June 2000. 

Availability
The source code, binaries, and file system utilities for NWFS 2.2 for Linux are 
available via ftp at 207.109.151.240, or can be downloaded from TRG's web site at 
www.timpanogas.com.   The NWFS 2.2 File System Source Code is being released under 
the GNU Public License, and is freely re-distributable.  Customers can  license 
NWFS 2.2 utilities via TRG's website.   Brainshare 2000 Promotional price for the 
NWFS 2.2 file system management tools for a single user license is $19.99 US until 
April 20, 2000.  Normal Retail for the NWFS 2.2 file system management tools for a 
single user license is $29.99 US.

About Timpanogas Research Group
TRG is a Utah corporation located in Orem, Utah.   TRG develops technology solutions 
for the networking, storage and clustering markets. For information on Timpanogas 
Research Group, its products and services, visit TRG's web site at www.timpanogas.com. 

Note: Timpanogas Research Group, TRG and FENRIS are trademarks of Timpanogas Research 
Group, Inc., in the United States and other countries. All other registered trademarks, 
trademarks and service marks are the property of their respective owners.
# # #
Press Contact:
Jeff Merkey
Timpanogas Research Group, Inc.
Phone: (801) 222-9129
Cell: (801) 361-9907
Internet: jmer...@timpanogas.com


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

From: "Jeff V. Merkey" <jmer...@timpanogas.com>
Subject: M2FS Open Source Clustering Announcement 3/29/00
Date: 2000/03/25
Message-ID: <fa.egdqj9v.12n2pps@ifi.uio.no>#1/1
X-Deja-AN: 602019310
Original-Date: Fri, 24 Mar 2000 17:55:42 -0700
Sender: owner-linux-ker...@vger.rutgers.edu
Original-Message-ID: <38DC0E8E.4DBECE3F@timpanogas.com>
To: linux-ker...@vger.rutgers.edu, linux-kernel-annou...@vger.rutgers.edu
X-Accept-Language: en
Content-Type: multipart/mixed
X-Orcpt: rfc822;linux-kernel-outgoing-dig
Organization: TRG, Inc.
MIME-Version: 1.0
Newsgroups: fa.linux.kernel
X-Loop: majord...@vger.rutgers.edu

FOR IMMEDIATE RELEASE - US1

Timpanogas Research Group( Announces the M-Squared (M2CS)  Clustered Storage 
System for Linux and Windows 2000, M-Squared Distributed File System (M2FS) for 
Linux and Windows 2000, and the NWFS-64 Open Source File System for IA64 Linux.

Orem, Utah - March 29, 2000 -  Timpanogas Research Group, Inc. located in Orem, 
Utah is pleased to announce the M-Squared Clustered Storage System (M2CS) for 
Linux and Windows 2000, the M-Squared Distributed File System (M2FS) for Linux 
and Windows 2000, and the NWFS-64 Open Source NetWare File System for IA64 Linux.

TRG's M2CS provides clustered storage capability for Linux and Windows 2000, 
allowing seamless and transparent clustering capability for existing Linux and 
Windows 2000 file systems.  M2CS also provides the ability for Linux and Windows 
2000 platforms to inter operate within a single cluster and share file system images 
between systems.    M2CS will be available for Novell's NetWare 5 platform.  TRG 
will post early releases of M2CS to it's website Q3 of 2000.  

TRG's M2FS is a fully clustered and distributed file system that provides file 
system level clustering capability for Linux and Windows 2000 within a single cluster.  
In addition to supporting a 64-bit on-disk format, M2FS also supports Native NetWare 
and NTFS on-disk formats, allowing customers to cluster existing NTFS and NetWare file 
systems cross-platform with Linux and Windows 2000 in a single clustered configuration, 
as well as providing support for a 64-bit M2FS Native File System formats.  M2FS will 
be available from TRG website at www.timpanogas.com Q4 2000.   

TRG is also pleased to announce the NWFS-64 Open Source NetWare File System for IA64 
Linux.  NWFS-64 is a  64-bit implementation of Novell's Native NetWare File System on 
the Linux Platform.  NWFS-64 for Linux Kernel 2.4 and above will be available Open 
Source from TRG's website at www.timpanogas.com June 2000. 

About Timpanogas Research Group
TRG is a Utah-based corporation founded in 1997 by Jeff Merkey and Darren Major. TRG 
is committed to the development of technology solutions for the networking, storage 
and clustering markets. For information on Timpanogas Research Group, its products 
and services, visit TRG's web site at www.timpanogas.com. 

Note: Timpanogas Research Group, TRG and FENRIS are trademarks of Timpanogas Research 
Group, Inc., in the United States and other countries. All other registered trademarks, 
trademarks and service marks are the property of their respective owners.
# # #
Press Contact:
Jeff Merkey
Timpanogas Research Group, Inc.
Phone: (801) 222-9129
Cell: (801) 361-9907
Internet: jmer...@timpanogas.com


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

From: "Jeff V. Merkey" <jmer...@timpanogas.com>
Subject: NWFS Source Code Posted at 207.109.151.240
Date: 2000/03/27
Message-ID: <fa.e3d0hgv.10goqhl@ifi.uio.no>
X-Deja-AN: 602936717
Original-Date: Mon, 27 Mar 2000 05:49:12 -0700
Sender: owner-linux-ker...@vger.rutgers.edu
Original-Message-ID: <38DF58C8.CE774275@timpanogas.com>
To: linux-ker...@vger.rutgers.edu
X-Accept-Language: en
Content-Type: multipart/mixed
X-Orcpt: rfc822;linux-kernel-outgoing-dig
Organization: TRG, Inc.
MIME-Version: 1.0
Newsgroups: fa.linux.kernel
X-Loop: majord...@vger.rutgers.edu


The Open Source Release of NWFS 2.2 for the Linux 2.0 and 2.2 kernels is
posted to our site at www.timpanogas.com and 207.109.151.240.  Included
are the release notes.  2.4 will be posted Wednesday, March 29, 2000 at
7:00 a.m. Eastern Time.

Jeff Merkey
CEO, TRG
--------------B7D27370EFDC8F86CFD69B7B
Content-Type: text/plain; charset=us-ascii;
 name="NOTES.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="NOTES.txt"


NWFS 2.2 RELEASE NOTES
----------------------

NWFS is a work in progress.  TRG will continue to develop enhancements
and new features to NWFS in the future.  You are encouraged to report
bugs or requests for feature enhancements to i...@timpanogas.com

This release supports Linux Kernels 2.0 and 2.2.  2.3 support will be
released Wednesday, January 29, 2000 at 7:00 a.m. Eastern Time
at www.timpanogas.com and will also be avialable via FTP at
207.109.151.240.

New To This Release:

1.  Full Asynch IO Manager (SMP)
2.  NetWare-ish LRU Mirrored Block Cache.
3.  Handle Based Virtual Partition Mirroring and Hotfixing Engine (NWVP).
4.  Full SMP Support (and we even tested it).

BUGS
----

There is a bug related to the interaction between NWFS and the 2.2 VFS
during "rm -r <directory>" operations where readdir from within rm is
getting confused and reading partial dentry blocks during recursive
delete operations.  The VFS interface for NWFS is contained in create.c,
dir.c, inode.c, file.c, mmap.c, nwvfs.c, and super.c.  The side affect
is that you will get a "directory not empty" message and have to
repeat the "rm -r" operation a couple of times until all the files
have been deleted.  Anyone out there with VFS 2.2 knowledge is welcome
to point out any apparent defects in the NWFS VFS interface for Linux.
2.3 also is manifesting similiar behavior at present.

There still may be deadlocks in the file system when boundry or low
memory conditions occur.  If you encounter one, rebuild with DEBUG_DEADLOCKS
set to 1 in the globals.h file.  You will be able to hit Control-C
and get a message about where the deadlock occurred.  email your
/var/log/messages file to jmer...@timpanogas.com (after compressing it
first) and we will get it fixed if anyone runs across any deadlocks
our testing scenarios did not expose.

At present, we are implementing hard links linux-style.  The method used
by NetWare NFS is extremely ackward, and implementations between NetWare
versions are different.  There is a HARD_LINKED flag however for files,
which allows vrepair under NetWare to fixup hard-linked directory records
during mount.

The NetWare NFS implementation of hard links does not allow the data stream
to "float" between inodes as is done in linux.  NetWare creates a root
directory record, chains the data stream to it, and if it gets deleted,
all the hard links lose their links to the data.  I have implemented
hard links linux-style, but probably should create some mapping layer to
move the root around when someone deletes it.


BUILDING NWFS
-------------

The globals.h file contains the following table of options:

#define  WINDOWS_NT_RO    0
#define  WINDOWS_NT       0
#define  WINDOWS_NT_UTIL  0
#define  WINDOWS_CONVERT  0
#define  WINDOWS_98_UTIL  0
#define  LINUX_20         0
#define  LINUX_22         1
#define  LINUX_24         0
#define  LINUX_UTIL       0
#define  DOS_UTIL         0

The LINUX_20 and LINUX_22 File System driver options are the only
driver versions covered under this particular release.  Select
either LINUX_20 or LINUX_22 and set to 1 in globals.h (you can only
select one at a time).

There are makefiles included for differnt kernel configurations.  To
make the NWFS driver for Linux, select one of the following.  The
makefiles support modversioned kernels and naked kernels.

make -f nwfs.mak         This will make an NWFS driver SMP-no  MODVER-no
make -f nwfsmod.mak      This will make an NWFS driver SMP-no  MODVER-yes
make -f nwfssmp.mak      This will make an NWFS driver SMP-yes MODVER-no
make -f nwmodsmp.mak     This will make an NWFS driver SMP-yes MODVER-yes


TO-DO-List.
-----------

The list has gotten very short, and few items remain (less platform
optimization work) for closure for NWFS on Linux relative to
providing all the features of the Native NetWare File System.
Tuning and performance work is always on-going.

1.  Implement Macintosh Data Fork Support and integrate with HFS code
on 2.2 and 2.3 for the Linux Macintosh File Service.

2.  Implement 255 character name support in the extended directory for
NFS and LONG namespaces (current is 80 character).

3.  Implement extensible parent hash skip lists for rapid positional
numeric probes of the parent hash (like readdir and lookup like to do).

4.  Add deleted block sequence number engine for salvageable file
system (rename Command needs to support -2 deleted file directory).

5.  Implement splay tree for hash buckets on name hashes instead of
linked lists for better search times.

6.  Implement hash in aio manager for rapid indexing during add io
requests (will do today).

7.  Finish Netware hard link support NetWare NFS style instead of
linux style (very ackward implementation).

8.  Implement cpu_to_le32(), etc. macros and test on IA64, Sparc64, and
Alpha64.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

From: Andi Kleen <a...@suse.de>
Subject: Re: NWFS Source Code Posted at 207.109.151.240
Date: 2000/03/27
Message-ID: <fa.ii7s0tv.1tmuv3k@ifi.uio.no>#1/1
X-Deja-AN: 602965498
Original-Date: 27 Mar 2000 17:36:58 +0200
Sender: owner-linux-ker...@vger.rutgers.edu
Original-Message-ID: <oupk8io77c5.fsf@pigdrop.muc.suse.de>
References: <fa.e3d0hgv.10goqhl@ifi.uio.no>
To: "Jeff V. Merkey" <jmer...@timpanogas.com>
Original-References: <38DF58C8.CE774...@timpanogas.com>
Content-Type: text/plain; charset=us-ascii
X-Orcpt: rfc822;linux-kernel-outgoing-dig
Organization: Internet mailing list
User-Agent: Gnus/5.0803 (Gnus v5.8.3) Emacs/20.6
MIME-Version: 1.0
Newsgroups: fa.linux.kernel
X-Loop: majord...@vger.rutgers.edu

"Jeff V. Merkey" <jmer...@timpanogas.com> writes:
> 
> 1.  Full Asynch IO Manager (SMP)

Could you expand a bit on your reasons to use an own buffer cache
instead of the standard Linux one ? Also what does this async
manager offer over the normal asynchronous block device interface ?

Thanks,

-Andi


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

From: "Jeff V. Merkey" <jmer...@timpanogas.com>
Subject: Re: NWFS Source Code Posted at 207.109.151.240
Date: 2000/03/27
Message-ID: <fa.e1rkn1v.137k61t@ifi.uio.no>#1/1
X-Deja-AN: 602979611
Original-Date: Mon, 27 Mar 2000 08:06:11 -0700
Sender: owner-linux-ker...@vger.rutgers.edu
Content-Transfer-Encoding: 7bit
Original-Message-ID: <38DF78E3.1EF50FE2@timpanogas.com>
References: <fa.ii7s0tv.1tmuv3k@ifi.uio.no>
To: Andi Kleen <a...@suse.de>
Original-References: <38DF58C8.CE774...@timpanogas.com> <oupk8io77c5....@pigdrop.muc.suse.de>
X-Accept-Language: en
Content-Type: text/plain; charset=us-ascii
X-Orcpt: rfc822;linux-kernel-outgoing-dig
Organization: TRG, Inc.
MIME-Version: 1.0
Newsgroups: fa.linux.kernel
X-Loop: majord...@vger.rutgers.edu


Andi,

The Linux Buffer Cache does not present a logical block cache for
NetWare's flavor of mirroring support, although basically what's there
is implemented as a Logical Block Cache on top of the Linux Buffer
Cache.  You will notice that NWFS can use either it's own LRU or the
linux buffer cache (there's an #if/#else/#endif for LINUX_BUFFER_CACHE
in block.c -- this will make NWFS sit on top of buffer.c).   You would
want to crank down the MAX_BLOCK_BUFFERS count in nwfs.h to something
smaller than 2000.

The Async processes bascially provides an elevator for remirroring and
concurrent mirroring I/O so the file system doesn't get starved.  It
sits on top of the linux disk interface.  These abstractions are also
necessary for our clustered file system for Linux (M2FS).  Look
carefully at the layering in nwvp.c, and it will be clear why we did
what we did.  

This code base also runs on several other platforms, and some of what is
there is not applicable to Linux, but is to NT and DOS.  The tools use
these interfaces and we have to have them as convinient abstractions
since they are not available on every platform (not all OS's are as
blessed as Linux).

What's here is a smaller version of the internal architecture of Native
NetWare.   Some of the services and what they do is a little different. 
I hope we are helping Linux?

Very Truly Yours,

Jeff



Andi Kleen wrote:
> 
> "Jeff V. Merkey" <jmer...@timpanogas.com> writes:
> >
> > 1.  Full Asynch IO Manager (SMP)
> 
> Could you expand a bit on your reasons to use an own buffer cache
> instead of the standard Linux one ? Also what does this async
> manager offer over the normal asynchronous block device interface ?
> 
> Thanks,
> 
> -Andi
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.rutgers.edu
> Please read the FAQ at http://www.tux.org/lkml/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

From: Pavel Machek <pa...@suse.cz>
Subject: Re: NWFS Source Code Posted at 207.109.151.240
Date: 2000/03/29
Message-ID: <fa.c1dhgbv.uku50n@ifi.uio.no>#1/1
X-Deja-AN: 603781369
Original-Date: Mon, 27 Mar 2000 21:50:18 +0200
Sender: owner-linux-ker...@vger.rutgers.edu
Original-Message-ID: <20000327215018.C3034@bug.ucw.cz>
References: <fa.e1rkn1v.137k61t@ifi.uio.no>
To: "Jeff V. Merkey" <jmer...@timpanogas.com>, Andi Kleen <a...@suse.de>
Original-References: <38DF58C8.CE774...@timpanogas.com> <oupk8io77c5....@pigdrop.muc.suse.de> <38DF78E3.1EF50...@timpanogas.com>
Content-Type: text/plain; charset=us-ascii
X-Orcpt: rfc822;linux-kernel-outgoing-dig
Organization: Internet mailing list
Mime-Version: 1.0
Newsgroups: fa.linux.kernel
X-Loop: majord...@vger.rutgers.edu

Hi!

> The Linux Buffer Cache does not present a logical block cache for
> NetWare's flavor of mirroring support, although basically what's there
> is implemented as a Logical Block Cache on top of the Linux Buffer
> Cache.  You will notice that NWFS can use either it's own LRU or the
> linux buffer cache (there's an #if/#else/#endif for LINUX_BUFFER_CACHE
> in block.c -- this will make NWFS sit on top of buffer.c).   You would
> want to crank down the MAX_BLOCK_BUFFERS count in nwfs.h to something
> smaller than 2000.
> 
> The Async processes bascially provides an elevator for remirroring and
> concurrent mirroring I/O so the file system doesn't get starved.  It
> sits on top of the linux disk interface.  These abstractions are also
> necessary for our clustered file system for Linux (M2FS).  Look
> carefully at the layering in nwvp.c, and it will be clear why we did
> what we did.  
> 
> This code base also runs on several other platforms, and some of what is
> there is not applicable to Linux, but is to NT and DOS.  The tools use
> these interfaces and we have to have them as convinient abstractions
> since they are not available on every platform (not all OS's are as
> blessed as Linux).
> 
> What's here is a smaller version of the internal architecture of Native
> NetWare.   Some of the services and what they do is a little different. 
> I hope we are helping Linux?

I did not read the sources, but putting additional abstraction layers
is considered evil... I don't think you can push nwfs into linus's
tree with design like that. It is fine for occasional access of nwfs
drives, through.
								Pavel
-- 
I'm pa...@ucw.cz. "In my country we have almost anarchy and I don't care."
Panos Katsaloulis describing me w.r.t. patents me at disc...@linmodems.org

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

From: "Jeff V. Merkey" <jmer...@timpanogas.com>
Subject: Re: NWFS Source Code Posted at 207.109.151.240
Date: 2000/03/29
Message-ID: <fa.e8seenv.p067q8@ifi.uio.no>#1/1
X-Deja-AN: 603794986
Original-Date: Wed, 29 Mar 2000 02:47:00 -0700
Sender: owner-linux-ker...@vger.rutgers.edu
Content-Transfer-Encoding: 7bit
Original-Message-ID: <38E1D114.2F14C774@timpanogas.com>
References: <fa.c1dhgbv.uku50n@ifi.uio.no>
To: Pavel Machek <pa...@suse.cz>
Original-References: <38DF58C8.CE774...@timpanogas.com> <oupk8io77c5....@pigdrop.muc.suse.de> <38DF78E3.1EF50...@timpanogas.com> <20000327215018.C3...@bug.ucw.cz>
X-Accept-Language: en
Content-Type: text/plain; charset=us-ascii
X-Orcpt: rfc822;linux-kernel-outgoing-dig
Organization: TRG, Inc.
MIME-Version: 1.0
Newsgroups: fa.linux.kernel
X-Loop: majord...@vger.rutgers.edu



Pavel Machek wrote:
> 
> Hi!
> 
> 
> I did not read the sources, but putting additional abstraction layers
> is considered evil... I don't think you can push nwfs into linus's
> tree with 

<   design like that  >. 

It's a design that Novell uses to gross more $$$$$$$ routinely in one
month than Linux has brought in with all the Linux companies revenues
combined in the past five years.  :-) 

It is fine for occasional access of nwfs
> drives, through.
>                                                                 Pavel
> --
> 

Dear Pavel,

Wasn't trying to push anything, there are lots of people who want
NetWare stuff, just trying to make Linux more attractive to Novell's
9,000,000 server installed base and get the NetWare file system on Linux
out the door.  You guys are always welcome to carve up NWFS like a
christmas turkey and chunk the pieces that don't make sense for Linux
moving forward.  You'll find I'm not too religious about the sanctity of
my own code, I'd rather be a contributor and team player with you guys. 
:-)  

With the page cache, the file systems in Linux are more or less reduced
to meta-data drivers (very similiar to where NT is at today).  The extra
layers are not really all that heavy, and are there to support our
clustering stuff (which we will open source as well).   Most of them use
fast paths in the code (which you will see if you take the time to look
at it).  Unlike most of the File System code in Linux, NWFS has
COMMENTS, NOTES, EXPLANATIONS, DETAILED TECHNICAL INFO, etc.  :-)

You guys might learn something by looking at it.  I am right at this
moment staring at the NCPFS code in 2.3.99Pre3 since there is NO
DOCUMENTATION ON THE PAGE CACHE, DCACHE, VFS or anything else here to
help besides pouring over source code.  :-)

Don't knock NetWare til you try it. :-)  

Your friend,

Jeff

I'm pa...@ucw.cz. "In my country we have almost anarchy and I don't
care."
> Panos Katsaloulis describing me w.r.t. patents me at disc...@linmodems.org
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.rutgers.edu
> Please read the FAQ at http://www.tux.org/lkml/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

From: "Jeff V. Merkey" <jmer...@timpanogas.com>
Subject: Re: NWFS Source Code Posted at 207.109.151.240
Date: 2000/03/29
Message-ID: <fa.egt2j8v.110mo9o@ifi.uio.no>#1/1
X-Deja-AN: 603800228
Original-Date: Wed, 29 Mar 2000 03:02:26 -0700
Sender: owner-linux-ker...@vger.rutgers.edu
Content-Transfer-Encoding: 7bit
Original-Message-ID: <38E1D4B2.D9DD8E44@timpanogas.com>
References: <fa.e8seenv.p067q8@ifi.uio.no>
To: Pavel Machek <pa...@suse.cz>, Andi Kleen <a...@suse.de>, linux-ker...@vger.rutgers.edu
Original-References: <38DF58C8.CE774...@timpanogas.com> <oupk8io77c5....@pigdrop.muc.suse.de> <38DF78E3.1EF50...@timpanogas.com> <20000327215018.C3...@bug.ucw.cz> <38E1D114.2F14C...@timpanogas.com>
X-Accept-Language: en
Content-Type: text/plain; charset=us-ascii
X-Orcpt: rfc822;linux-kernel-outgoing-dig
Organization: TRG, Inc.
MIME-Version: 1.0
Newsgroups: fa.linux.kernel
X-Loop: majord...@vger.rutgers.edu


Pavel,

Oh Yeah, and I almost forgot.  Remember those emails I sent you 6 months
ago. The one's asking for your help with creating an md driver for the
NetWare mirroring so I didn't have to replicate a NetWare style LRU so I
could tightly integrate NWFS with the Linux Buffer Cache and md (in
fact, I even was willing to give you the nwvp code and sent it to you so
you could put it into the current RAID driver)?

Did you ever respond.   NO ......

How many emails did I send you?   Was it seven or eight?

Did you answer any of them.  NO .......

If you are still interested in doing what I suggested, unlike you, I
will answer your emails and help you take over the code (and let you
control it for Linux) so Linux will be able to enter Novell's market
with a tighter implementation.

Think about it ......

:-) :-) :-).

Touche .....

Jeff


"Jeff V. Merkey" wrote:
> 
> Pavel Machek wrote:
> >
> > Hi!
> >
> >
> > I did not read the sources, but putting additional abstraction layers
> > is considered evil... I don't think you can push nwfs into linus's
> > tree with
> 
> <   design like that  >.
> 
> It's a design that Novell uses to gross more $$$$$$$ routinely in one
> month than Linux has brought in with all the Linux companies revenues
> combined in the past five years.  :-)
> 
> It is fine for occasional access of nwfs
> > drives, through.
> >                                                                 Pavel
> > --
> >
> 
> Dear Pavel,
> 
> Wasn't trying to push anything, there are lots of people who want
> NetWare stuff, just trying to make Linux more attractive to Novell's
> 9,000,000 server installed base and get the NetWare file system on Linux
> out the door.  You guys are always welcome to carve up NWFS like a
> christmas turkey and chunk the pieces that don't make sense for Linux
> moving forward.  You'll find I'm not too religious about the sanctity of
> my own code, I'd rather be a contributor and team player with you guys.
> :-)
> 
> With the page cache, the file systems in Linux are more or less reduced
> to meta-data drivers (very similiar to where NT is at today).  The extra
> layers are not really all that heavy, and are there to support our
> clustering stuff (which we will open source as well).   Most of them use
> fast paths in the code (which you will see if you take the time to look
> at it).  Unlike most of the File System code in Linux, NWFS has
> COMMENTS, NOTES, EXPLANATIONS, DETAILED TECHNICAL INFO, etc.  :-)
> 
> You guys might learn something by looking at it.  I am right at this
> moment staring at the NCPFS code in 2.3.99Pre3 since there is NO
> DOCUMENTATION ON THE PAGE CACHE, DCACHE, VFS or anything else here to
> help besides pouring over source code.  :-)
> 
> Don't knock NetWare til you try it. :-)
> 
> Your friend,
> 
> Jeff
> 
> I'm pa...@ucw.cz. "In my country we have almost anarchy and I don't
> care."
> > Panos Katsaloulis describing me w.r.t. patents me at disc...@linmodems.org
> >
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to majord...@vger.rutgers.edu
> > Please read the FAQ at http://www.tux.org/lkml/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

From: "Andi Kleen" <a...@suse.de>
Subject: Re: NWFS Source Code Posted at 207.109.151.240
Date: 2000/03/29
Message-ID: <fa.fq4jhsv.l4eirp@ifi.uio.no>#1/1
X-Deja-AN: 603803376
Original-Date: Wed, 29 Mar 2000 12:20:52 +0200
Sender: owner-linux-ker...@vger.rutgers.edu
Original-Message-ID: <20000329122052.A7906@gruyere.muc.suse.de>
References: <fa.e8seenv.p067q8@ifi.uio.no>
To: "Jeff V. Merkey" <jmer...@timpanogas.com>
Original-References: <38DF58C8.CE774...@timpanogas.com> <oupk8io77c5....@pigdrop.muc.suse.de> <38DF78E3.1EF50...@timpanogas.com> <20000327215018.C3...@bug.ucw.cz> <38E1D114.2F14C...@timpanogas.com>
Content-Type: text/plain; charset=us-ascii
X-Orcpt: rfc822;linux-kernel-outgoing-dig
Organization: Internet mailing list
Mime-Version: 1.0
Newsgroups: fa.linux.kernel
X-Loop: majord...@vger.rutgers.edu

On Wed, Mar 29, 2000 at 02:47:00AM -0700, Jeff V. Merkey wrote:
> Wasn't trying to push anything, there are lots of people who want
> NetWare stuff, just trying to make Linux more attractive to Novell's
> 9,000,000 server installed base and get the NetWare file system on Linux
> out the door.  You guys are always welcome to carve up NWFS like a
> christmas turkey and chunk the pieces that don't make sense for Linux
> moving forward.  You'll find I'm not too religious about the sanctity of
> my own code, I'd rather be a contributor and team player with you guys. 
> :-)  

It is not clear to me how the mmap in your code syncs data to disk.
You don't have a vma sync operation implemented, but you use an private
buffer for the mmap page cache. How does the data get back when changed ?

-Andi


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

From: "Jeff V. Merkey" <jmer...@timpanogas.com>
Subject: Re: NWFS Source Code Posted at 207.109.151.240
Date: 2000/03/29
Message-ID: <fa.edssi0v.110sr1s@ifi.uio.no>#1/1
X-Deja-AN: 603805640
Original-Date: Wed, 29 Mar 2000 03:20:05 -0700
Sender: owner-linux-ker...@vger.rutgers.edu
Content-Transfer-Encoding: 7bit
Original-Message-ID: <38E1D8D5.11C1DF0A@timpanogas.com>
References: <fa.fq4jhsv.l4eirp@ifi.uio.no>
To: Andi Kleen <a...@suse.de>
Original-References: <38DF58C8.CE774...@timpanogas.com> <oupk8io77c5....@pigdrop.muc.suse.de> <38DF78E3.1EF50...@timpanogas.com> <20000327215018.C3...@bug.ucw.cz> <38E1D114.2F14C...@timpanogas.com> <20000329122052.A7...@gruyere.muc.suse.de>
X-Accept-Language: en
Content-Type: text/plain; charset=us-ascii
X-Orcpt: rfc822;linux-kernel-outgoing-dig
Organization: TRG, Inc.
MIME-Version: 1.0
Newsgroups: fa.linux.kernel
X-Loop: majord...@vger.rutgers.edu




Andi Kleen wrote:
> 
 
> It is not clear to me how the mmap in your code syncs data to disk.
> You don't have a vma sync operation implemented, but you use an private
> buffer for the mmap page cache. How does the data get back when changed ?
> 
> -Andi


This is implemented the same way it is in the FAT and NCPFS file
systems.  How do they write the data back when changed?

Jeff

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

From: "Andi Kleen" <a...@suse.de>
Subject: Re: NWFS Source Code Posted at 207.109.151.240
Date: 2000/03/29
Message-ID: <fa.fo49k5v.g4kijv@ifi.uio.no>#1/1
X-Deja-AN: 603810749
Original-Date: Wed, 29 Mar 2000 12:47:04 +0200
Sender: owner-linux-ker...@vger.rutgers.edu
Original-Message-ID: <20000329124704.A8277@gruyere.muc.suse.de>
References: <fa.edssi0v.110sr1s@ifi.uio.no>
To: "Jeff V. Merkey" <jmer...@timpanogas.com>
Original-References: <38DF58C8.CE774...@timpanogas.com> <oupk8io77c5....@pigdrop.muc.suse.de> <38DF78E3.1EF50...@timpanogas.com> <20000327215018.C3...@bug.ucw.cz> <38E1D114.2F14C...@timpanogas.com> <20000329122052.A7...@gruyere.muc.suse.de> <38E1D8D5.11C1D...@timpanogas.com>
Content-Type: text/plain; charset=us-ascii
X-Orcpt: rfc822;linux-kernel-outgoing-dig
Organization: Internet mailing list
Mime-Version: 1.0
Newsgroups: fa.linux.kernel
X-Loop: majord...@vger.rutgers.edu

On Wed, Mar 29, 2000 at 03:20:05AM -0700, Jeff V. Merkey wrote:
> 
> 
> 
> Andi Kleen wrote:
> > 
>  
> > It is not clear to me how the mmap in your code syncs data to disk.
> > You don't have a vma sync operation implemented, but you use an private
> > buffer for the mmap page cache. How does the data get back when changed ?
> > 
> > -Andi
> 
> 
> This is implemented the same way it is in the FAT and NCPFS file
> systems.  How do they write the data back when changed?

I don't know. Unless I'm missing something (which is quite possible)
they don't sync.
Have you tested shared mappings to be functional ?


-Andi

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

From: "Jeff V. Merkey" <jmer...@timpanogas.com>
Subject: Re: NWFS Source Code Posted at 207.109.151.240
Date: 2000/03/29
Message-ID: <fa.epsu8vv.r0uq2c@ifi.uio.no>#1/1
X-Deja-AN: 603816845
Original-Date: Wed, 29 Mar 2000 03:55:28 -0700
Sender: owner-linux-ker...@vger.rutgers.edu
Content-Transfer-Encoding: 7bit
Original-Message-ID: <38E1E120.D04C952F@timpanogas.com>
References: <fa.fo49k5v.g4kijv@ifi.uio.no>
To: Andi Kleen <a...@suse.de>
Original-References: <38DF58C8.CE774...@timpanogas.com> <oupk8io77c5....@pigdrop.muc.suse.de> <38DF78E3.1EF50...@timpanogas.com> <20000327215018.C3...@bug.ucw.cz> <38E1D114.2F14C...@timpanogas.com> <20000329122052.A7...@gruyere.muc.suse.de> <38E1D8D5.11C1D...@timpanogas.com> <20000329124704.A8...@gruyere.muc.suse.de>
X-Accept-Language: en
Content-Type: text/plain; charset=us-ascii
X-Orcpt: rfc822;linux-kernel-outgoing-dig
Organization: TRG, Inc.
MIME-Version: 1.0
Newsgroups: fa.linux.kernel
X-Loop: majord...@vger.rutgers.edu



Andi Kleen wrote:
> 
> > This is implemented the same way it is in the FAT and NCPFS file
> > systems.  How do they write the data back when changed?
> 
> I don't know. Unless I'm missing something (which is quite possible)
> they don't sync.
> Have you tested shared mappings to be functional ?
> 

No, I have not.  This could possibly mean that the other FS's are
incorrect as well.  Please feel free to map out a skeleton vma_sync
function (or point me down the road and I'll go look somewhere for the
stuff) and send to me, and I'll integrate it.  I'd love for some SUSE
guys to be involved in the NWFS project.  

By the way, Larry Angus (Our operations VP) won't use Open Linux, and
occasionally uses RedHat Linux, but my entire lab is filled with SUSE
linux (and I have the bills to prove it).  Our VP of engineering has
rated your distribution the best overall for all of our testing, and
it's what we use as a baseline platform.  FYI.  I use RedHat and Open
Linux (we test with Open Linux as well, but it's not the most prevelant
here).

:-)

Jeff

 



> -Andi

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

From: "Andi Kleen" <a...@suse.de>
Subject: Re: NWFS Source Code Posted at 207.109.151.240
Date: 2000/03/29
Message-ID: <fa.fq47jcv.h4ijrp@ifi.uio.no>#1/1
X-Deja-AN: 603823166
Original-Date: Wed, 29 Mar 2000 13:32:34 +0200
Sender: owner-linux-ker...@vger.rutgers.edu
Original-Message-ID: <20000329133234.A9054@gruyere.muc.suse.de>
References: <fa.epsu8vv.r0uq2c@ifi.uio.no>
To: "Jeff V. Merkey" <jmer...@timpanogas.com>
Original-References: <38DF58C8.CE774...@timpanogas.com> <oupk8io77c5....@pigdrop.muc.suse.de> <38DF78E3.1EF50...@timpanogas.com> <20000327215018.C3...@bug.ucw.cz> <38E1D114.2F14C...@timpanogas.com> <20000329122052.A7...@gruyere.muc.suse.de> <38E1D8D5.11C1D...@timpanogas.com> <20000329124704.A8...@gruyere.muc.suse.de> <38E1E120.D04C9...@timpanogas.com>
Content-Type: text/plain; charset=us-ascii
X-Orcpt: rfc822;linux-kernel-outgoing-dig
Organization: Internet mailing list
Mime-Version: 1.0
Newsgroups: fa.linux.kernel
X-Loop: majord...@vger.rutgers.edu

On Wed, Mar 29, 2000 at 03:55:28AM -0700, Jeff V. Merkey wrote:
> 
> 
> Andi Kleen wrote:
> > 
> > > This is implemented the same way it is in the FAT and NCPFS file
> > > systems.  How do they write the data back when changed?
> > 
> > I don't know. Unless I'm missing something (which is quite possible)
> > they don't sync.
> > Have you tested shared mappings to be functional ?
> > 
> 
> No, I have not.  This could possibly mean that the other FS's are

Shame on me, I missed that: 

int nwfs_mmap(struct file * file, struct vm_area_struct * vma)
{
    struct inode *inode = file->f_dentry->d_inode;

    if (vma->vm_flags & VM_SHARED)   // only PAGE_COW or read-only supported now
       return -EINVAL;

I guess supporting shared mappings would be useful though for a 
general purpose filesystem, because more and more programs use them. 

To fix it I think it is needed to implement unmap and sync 
vma operations that write the data to the file. 

That still has some problems over fully page cache integrated filesystems
like ext2 (user has to call msync to see updates in read/write and it is
slower), but would at least make them work. 


-Andi


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

From: "Jeff V. Merkey" <jmer...@timpanogas.com>
Subject: Re: NWFS Source Code Posted at 207.109.151.240
Date: 2000/03/29
Message-ID: <fa.e8d0c0v.rgsp1i@ifi.uio.no>#1/1
X-Deja-AN: 603827238
Original-Date: Wed, 29 Mar 2000 04:30:15 -0700
Sender: owner-linux-ker...@vger.rutgers.edu
Content-Transfer-Encoding: 7bit
Original-Message-ID: <38E1E947.5891A7F5@timpanogas.com>
References: <fa.fq47jcv.h4ijrp@ifi.uio.no>
To: Andi Kleen <a...@suse.de>
Original-References: <38DF58C8.CE774...@timpanogas.com> <oupk8io77c5....@pigdrop.muc.suse.de> <38DF78E3.1EF50...@timpanogas.com> <20000327215018.C3...@bug.ucw.cz> <38E1D114.2F14C...@timpanogas.com> <20000329122052.A7...@gruyere.muc.suse.de> <38E1D8D5.11C1D...@timpanogas.com> <20000329124704.A8...@gruyere.muc.suse.de> <38E1E120.D04C9...@timpanogas.com> <20000329133234.A9...@gruyere.muc.suse.de>
X-Accept-Language: en
Content-Type: text/plain; charset=us-ascii
X-Orcpt: rfc822;linux-kernel-outgoing-dig
Organization: TRG, Inc.
MIME-Version: 1.0
Newsgroups: fa.linux.kernel
X-Loop: majord...@vger.rutgers.edu



Andi Kleen wrote:
> 
> On Wed, Mar 29, 2000 at 03:55:28AM -0700, Jeff V. Merkey wrote:
> >
> >
> > Andi Kleen wrote:
> > >
> > > > This is implemented the same way it is in the FAT and NCPFS file
> > > > systems.  How do they write the data back when changed?
> > >
> > > I don't know. Unless I'm missing something (which is quite possible)
> > > they don't sync.
> > > Have you tested shared mappings to be functional ?
> > >
> >
> > No, I have not.  This could possibly mean that the other FS's are
> 
> Shame on me, I missed that:
> 
> int nwfs_mmap(struct file * file, struct vm_area_struct * vma)
> {
>     struct inode *inode = file->f_dentry->d_inode;
> 
>     if (vma->vm_flags & VM_SHARED)   // only PAGE_COW or read-only supported now
>        return -EINVAL;
> 
> I guess supporting shared mappings would be useful though for a
> general purpose filesystem, because more and more programs use them.
> 
> To fix it I think it is needed to implement unmap and sync
> vma operations that write the data to the file.
> 

Be my guest.  I'll add your name and code to the NWFS release if you
want to put it in.  Pavel can own the mirrorng, and rip it out of the FS
proper and put it at the raid level (and I'll change the FS to use it
this way -- Darren Major's preference anyway)  You may own all the mmap,
bmap, smap, etc-map issues (I have not implemented several of them but
need to).  I have to spend too much time working on NT file systems
(which are so ugly compared to the simplicity and elegance of Linux
VFS).

Jeff


> That still has some problems over fully page cache integrated filesystems
> like ext2 (user has to call msync to see updates in read/write and it is
> slower), but would at least make them work.
> 
> -Andi

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

From: Steve Dodd <ste...@loth.demon.co.uk>
Subject: Re: NWFS Source Code Posted at 207.109.151.240
Date: 2000/03/29
Message-ID: <fa.hdf9l1v.gjibg2@ifi.uio.no>#1/1
X-Deja-AN: 603949265
Original-Date: Wed, 29 Mar 2000 18:03:45 +0100
Sender: owner-linux-ker...@vger.rutgers.edu
Original-Message-ID: <20000329180345.A9262@loth.demon.co.uk>
References: <fa.e1rkn1v.137k61t@ifi.uio.no>
To: "Jeff V. Merkey" <jmer...@timpanogas.com>
Original-References: <38DF58C8.CE774...@timpanogas.com> <oupk8io77c5....@pigdrop.muc.suse.de> <38DF78E3.1EF50...@timpanogas.com>
Content-Type: text/plain; charset=us-ascii
X-Orcpt: rfc822;linux-kernel-outgoing-dig
Organization: Internet mailing list
Mime-Version: 1.0
User-Agent: Mutt/1.1.2i
Newsgroups: fa.linux.kernel
X-Loop: majord...@vger.rutgers.edu

[I've reordered the quotes, hope nobody minds; also cc'd fsdevel]

On Mon, Mar 27, 2000 at 08:06:11AM -0700, Jeff V. Merkey wrote:
> Andi Kleen wrote:

> > Could you expand a bit on your reasons to use an own buffer cache
> > instead of the standard Linux one ? Also what does this async
> > manager offer over the normal asynchronous block device interface ?
[..]

> The Linux Buffer Cache does not present a logical block cache for
> NetWare's flavor of mirroring support, although basically what's there
> is implemented as a Logical Block Cache on top of the Linux Buffer
> Cache. [..]

AIUI [0], Al Viro, Stephen Tweedie, and a number of others have some
interesting plans for the block device layer, buffer cache and page cache,
and the interactions between them and with the VFS -- for 2.5. I assume
they're busy with tidying up 2.4pre loose ends at the moment, but hopefully
after 2.4 is out the door and stable there will be some discussion of the
planned changes on linux-fsdevel. It sounds (I've not looked at your code yet)
like your input would be useful when that happens. An I/O system that meets
everyone's needs for 2.6 would be a great goal..

BTW, regarding your comments about Linux documentation - have you looked at
the work Alan Cox is doing on this yet?

Cheers,
Steve

[0] Which is probably not very well..

-- 
By doing just a little every day, you can gradually let the task
completely overwhelm you.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

From: "Jeff V. Merkey" <jmer...@timpanogas.com>
Subject: Re: NWFS Source Code Posted at 207.109.151.240
Date: 2000/03/29
Message-ID: <fa.es2gd2v.1l68drc@ifi.uio.no>#1/1
X-Deja-AN: 604012253
Original-Date: Wed, 29 Mar 2000 12:35:05 -0700
Sender: owner-linux-ker...@vger.rutgers.edu
Content-Transfer-Encoding: 7bit
Original-Message-ID: <38E25AE9.5D59289@timpanogas.com>
References: <fa.hdf9l1v.gjibg2@ifi.uio.no>
To: Steve Dodd <ste...@loth.demon.co.uk>
Original-References: <38DF58C8.CE774...@timpanogas.com> <oupk8io77c5....@pigdrop.muc.suse.de> <38DF78E3.1EF50...@timpanogas.com> <20000329180345.A9...@loth.demon.co.uk>
X-Accept-Language: en
Content-Type: text/plain; charset=us-ascii
X-Orcpt: rfc822;linux-kernel-outgoing-dig
Organization: TRG, Inc.
MIME-Version: 1.0
Newsgroups: fa.linux.kernel
X-Loop: majord...@vger.rutgers.edu



Steve Dodd wrote:

> AIUI [0], Al Viro, Stephen Tweedie, and a number of others have some
> interesting plans for the block device layer, buffer cache and page cache,
> and the interactions between them and with the VFS -- for 2.5. I assume
> they're busy with tidying up 2.4pre loose ends at the moment, but hopefully
> after 2.4 is out the door and stable there will be some discussion of the
> planned changes on linux-fsdevel. It sounds (I've not looked at your code yet)
> like your input would be useful when that happens. An I/O system that meets
> everyone's needs for 2.6 would be a great goal..
> 
> BTW, regarding your comments about Linux documentation - have you looked at
> the work Alan Cox is doing on this yet?
> 

Yes, i've looked at Alan's Documentation stuff.  And as always, Alan's
work is absolutely excellent -- however, what's really needed is
something like NT puts out with their IFS Kits, a sample VFS code
example for a NULL file system for folks who are porting to Linux. 
Would cut down on time along with an "oh shit" list of interface issues
to watch out for.  Richard Gooch did a decent job on the vfs.txt file
(it was better than nothing).  We need more though to get on par with
NT.

Jeff


> Cheers,
> Steve
> 
> [0] Which is probably not very well..
> 
> --
> By doing just a little every day, you can gradually let the task
> completely overwhelm you.
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.rutgers.edu
> Please read the FAQ at http://www.tux.org/lkml/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

From: Alan Cox <a...@lxorguk.ukuu.org.uk>
Subject: Re: NWFS Source Code Posted at 207.109.151.240
Date: 2000/03/29
Message-ID: <fa.griiv0v.1rmimgc@ifi.uio.no>#1/1
X-Deja-AN: 604043288
Original-Date: Wed, 29 Mar 2000 21:45:41 +0100 (BST)
Sender: owner-linux-ker...@vger.rutgers.edu
Original-Message-Id: <E12aPLS-0002od-00@the-village.bc.nu>
Content-Transfer-Encoding: 7bit
References: <fa.es2gd2v.1l68drc@ifi.uio.no>
To: jmer...@timpanogas.com (Jeff V. Merkey)
Content-Type: text/plain; charset=us-ascii
X-Orcpt: rfc822;linux-kernel-outgoing-dig
Organization: Internet mailing list
MIME-Version: 1.0
Newsgroups: fa.linux.kernel
X-Loop: majord...@vger.rutgers.edu

> Yes, i've looked at Alan's Documentation stuff.  And as always, Alan's
> work is absolutely excellent -- however, what's really needed is
> something like NT puts out with their IFS Kits, a sample VFS code

Documenting the functions is the first project, then the structures.

> to watch out for.  Richard Gooch did a decent job on the vfs.txt file
> (it was better than nothing).  We need more though to get on par with
> NT.

Yep - but documentation is boring and uncool.. unfortunately too many programmers
believe this. Documentation is worth it just to be able to answer all your
mail with 'RTFM'


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

From: "Jeff V. Merkey" <jmer...@timpanogas.com>
Subject: Re: NWFS Source Code Posted at 207.109.151.240
Date: 2000/03/29
Message-ID: <fa.eaduhgv.qnuqhv@ifi.uio.no>#1/1
X-Deja-AN: 604058130
Original-Date: Wed, 29 Mar 2000 13:59:40 -0700
Sender: owner-linux-ker...@vger.rutgers.edu
Content-Transfer-Encoding: 7bit
Original-Message-ID: <38E26EBC.850FAB53@timpanogas.com>
References: <fa.griiv0v.1rmimgc@ifi.uio.no>
To: Alan Cox <a...@lxorguk.ukuu.org.uk>
Original-References: <E12aPLS-0002od...@the-village.bc.nu>
X-Accept-Language: en
Content-Type: text/plain; charset=us-ascii
X-Orcpt: rfc822;linux-kernel-outgoing-dig
Organization: TRG, Inc.
MIME-Version: 1.0
Newsgroups: fa.linux.kernel
X-Loop: majord...@vger.rutgers.edu



Alan Cox wrote:
> 
> > Yes, i've looked at Alan's Documentation stuff.  And as always, Alan's
> > work is absolutely excellent -- however, what's really needed is
> > something like NT puts out with their IFS Kits, a sample VFS code
> 
> Documenting the functions is the first project, then the structures.
> 
> > to watch out for.  Richard Gooch did a decent job on the vfs.txt file
> > (it was better than nothing).  We need more though to get on par with
> > NT.
> 
> Yep - but documentation is boring and uncool.. unfortunately too many programmers
> believe this. Documentation is worth it just to be able to answer all your
> mail with 'RTFM'

I'll volunteer to create a NULL file system driver and maintain it --
along with docs.

Jeff

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

From: Alan Cox <a...@lxorguk.ukuu.org.uk>
Subject: Re: NWFS Source Code Posted at 207.109.151.240
Date: 2000/03/29
Message-ID: <fa.gtjf70v.1lm2ugc@ifi.uio.no>#1/1
X-Deja-AN: 604061217
Original-Date: Wed, 29 Mar 2000 22:16:05 +0100 (BST)
Sender: owner-linux-ker...@vger.rutgers.edu
Original-Message-Id: <E12aPos-0002sO-00@the-village.bc.nu>
Content-Transfer-Encoding: 7bit
References: <fa.eaduhgv.qnuqhv@ifi.uio.no>
To: jmer...@timpanogas.com (Jeff V. Merkey)
Content-Type: text/plain; charset=us-ascii
X-Orcpt: rfc822;linux-kernel-outgoing-dig
Organization: Internet mailing list
MIME-Version: 1.0
Newsgroups: fa.linux.kernel
X-Loop: majord...@vger.rutgers.edu

> I'll volunteer to create a NULL file system driver and maintain it --
> along with docs.

That would be great



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

From: Matthew Kirkwood <weej...@ferret.lmh.ox.ac.uk>
Subject: Re: NWFS Source Code Posted at 207.109.151.240
Date: 2000/03/29
Message-ID: <fa.lqodkbv.1p5e70d@ifi.uio.no>#1/1
X-Deja-AN: 604062991
Original-Date: Wed, 29 Mar 2000 22:17:12 +0100 (BST)
Sender: owner-linux-ker...@vger.rutgers.edu
Original-Message-ID: <Pine.LNX.4.21.0003292158300.30774-100000@ferret.lmh.ox.ac.uk>
References: <fa.es2gd2v.1l68drc@ifi.uio.no>
To: "Jeff V. Merkey" <jmer...@timpanogas.com>
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Orcpt: rfc822;linux-kernel-outgoing-dig
Organization: Internet mailing list
MIME-Version: 1.0
Newsgroups: fa.linux.kernel
X-Loop: majord...@vger.rutgers.edu

On Wed, 29 Mar 2000, Jeff V. Merkey wrote:

> > BTW, regarding your comments about Linux documentation - have you looked
> > at the work Alan Cox is doing on this yet?
>
> Yes, i've looked at Alan's Documentation stuff.  And as always, Alan's
> work is absolutely excellent -- however, what's really needed is
> something like NT puts out with their IFS Kits,

The IFS kits are export restricted.

> a sample VFS code example for a NULL file system for folks who are
> porting to Linux.

As I understand it, your nwfs is probably the first filesystem to
have been successfully "ported" to Linux.  Pretty much everything
else (with, perhaps, the exception of the abomination that is the
NTFS driver) started off native.

The multiple times that I have written 30 to 70% of a filesystem,
I found the romfs and minixfs code to be most instructive as a
guide to the VFS interfaces.  The buffer and page cache stuff is
rather harder to track down canonical examples for, though again
minixfs is pretty helpful, if rather simplistic.

Matthew.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

From: "Jeff V. Merkey" <jmer...@timpanogas.com>
Subject: Re: NWFS Source Code Posted at 207.109.151.240
Date: 2000/03/29
Message-ID: <fa.ejcshvv.11g4qid@ifi.uio.no>#1/1
X-Deja-AN: 604072755
Original-Date: Wed, 29 Mar 2000 14:38:44 -0700
Sender: owner-linux-ker...@vger.rutgers.edu
Content-Transfer-Encoding: 7bit
Original-Message-ID: <38E277E4.4C2DB32F@timpanogas.com>
References: <fa.gtjf70v.1lm2ugc@ifi.uio.no>
To: Alan Cox <a...@lxorguk.ukuu.org.uk>
Original-References: <E12aPos-0002sO...@the-village.bc.nu>
X-Accept-Language: en
Content-Type: text/plain; charset=us-ascii
X-Orcpt: rfc822;linux-kernel-outgoing-dig
Organization: TRG, Inc.
MIME-Version: 1.0
Newsgroups: fa.linux.kernel
X-Loop: majord...@vger.rutgers.edu



Alan Cox wrote:
> 
> > I'll volunteer to create a NULL file system driver and maintain it --
> > along with docs.
> 
> That would be great

Done!

Jeff

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

From: "Jeff V. Merkey" <jmer...@timpanogas.com>
Subject: Re: NWFS Source Code Posted at 207.109.151.240
Date: 2000/03/29
Message-ID: <fa.e7subpv.p0u79u@ifi.uio.no>#1/1
X-Deja-AN: 604074897
Original-Date: Wed, 29 Mar 2000 14:43:38 -0700
Sender: owner-linux-ker...@vger.rutgers.edu
Content-Transfer-Encoding: 7bit
Original-Message-ID: <38E2790A.4BCCA0E0@timpanogas.com>
References: <fa.lqodkbv.1p5e70d@ifi.uio.no>
To: Matthew Kirkwood <weej...@ferret.lmh.ox.ac.uk>
Original-References: <Pine.LNX.4.21.0003292158300.30774-100...@ferret.lmh.ox.ac.uk>
X-Accept-Language: en
Content-Type: text/plain; charset=us-ascii
X-Orcpt: rfc822;linux-kernel-outgoing-dig
Organization: TRG, Inc.
MIME-Version: 1.0
Newsgroups: fa.linux.kernel
X-Loop: majord...@vger.rutgers.edu



Matthew Kirkwood wrote:
> 
> On Wed, 29 Mar 2000, Jeff V. Merkey wrote:
> 
> > > BTW, regarding your comments about Linux documentation - have you looked
> > > at the work Alan Cox is doing on this yet?
> >
> > Yes, i've looked at Alan's Documentation stuff.  And as always, Alan's
> > work is absolutely excellent -- however, what's really needed is
> > something like NT puts out with their IFS Kits,
> 
> The IFS kits are export restricted.

True, but they are rife with examples, docs, and code.  The NT IFS is
one of the most complex beasts I've ever worked on.  The [ ... try {}
finally ... } C++ exception handling is what makes it so complex --
unwind cases from the VM Cache Manager can be very challening.  

> 
> > a sample VFS code example for a NULL file system for folks who are
> > porting to Linux.
> 
> As I understand it, your nwfs is probably the first filesystem to
> have been successfully "ported" to Linux.  Pretty much everything
> else (with, perhaps, the exception of the abomination that is the
> NTFS driver) started off native.
> 
> The multiple times that I have written 30 to 70% of a filesystem,
> I found the romfs and minixfs code to be most instructive as a
> guide to the VFS interfaces.  The buffer and page cache stuff is
> rather harder to track down canonical examples for, though again
> minixfs is pretty helpful, if rather simplistic.
>

I agree that the Minix code is a great example -- I use it for reference
as well.  

Jeff
 
> Matthew.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

From: "Jeff V. Merkey" <jmer...@timpanogas.com>
Subject: NWFS 2.2.2 Source Code for Linux Kernels 2.0/2.2/2.4 Released
Date: 2000/03/31
Message-ID: <fa.efdoegv.11n0729@ifi.uio.no>
X-Deja-AN: 604982237
Original-Date: Fri, 31 Mar 2000 12:32:47 -0700
Sender: owner-linux-ker...@vger.rutgers.edu
Content-Transfer-Encoding: 7bit
Original-Message-ID: <38E4FD5F.BEE0535C@timpanogas.com>
To: linux-ker...@vger.rutgers.edu
X-Accept-Language: en
Content-Type: text/plain; charset=us-ascii
X-Orcpt: rfc822;linux-kernel-outgoing-dig
Organization: TRG, Inc.
MIME-Version: 1.0
Newsgroups: fa.linux.kernel
X-Loop: majord...@vger.rutgers.edu



The NWFS 2.2.2 Open Source Code has been posted, and is available for
download at www.timpanogas.com or 207.109.151.240.  The files
nwfs0331.zip and nwfs0331.tar.gz contain this release.  There is still
much work to do on Linux 2.4.  Support for Linux Kernel's 2.0/2.2 is
nearing completion.

Jeff Merkey
CEO, TRG



NWFS 2.2.2 RELEASE NOTES
------------------------

NWFS is a work in progress.  TRG will continue to develop enhancements
and new features to NWFS in the future.  You are encouraged to report
bugs or requests for feature enhancements to i...@timpanogas.com

This release supports Linux Kernels 2.0 and 2.2 and 2.4

BUGS
----

We are still implementing and testing the rm -r bug.  This bug seems
to be fixed.  Another release will probably happen this weekend after
we cook it some more in the lab.

There is also an implementation bug in the way we are creating our 
own buffer heads and performing ASYNCH IO on 2.4 Only. We have a fix 
for this bug.  For now, NWFS for 2.4 is configured to use the Linux
buffer cache until this fix is posted this weekend or Monday.

Linux Kernel 2.4 removed some exported API's necessary for NWFS to
support mirroring and striping on Linux.  NWFS must scan all disks 
in a Linux server with valid NetWare partitions in order to build 
a complete map of all stripped volume segments and mirror group memebers
before any NetWare volumes can be mounted (you have to locate a volume's
segments and mirror members).  We are implementing the
necessary functions in block_dev.c and will provide a patch for 
Linux 2.4 until these changes are submitted to the Linux Kernel
folks next week.  At present, we have hard coded disk 0 for
testing purposes until this fix gets in.  NWFS is fully 
functional and can perform the disk scanning under 2.0 and 2.2 
but not 2.4 until we have implemented the workaround.

The VM Cache Manager Interface used by NWFS under Windows NT/2000 is 
almost identical in form and function to the design and implementation
of the page cache in Linux.  As such, we are restructuring this code
and are porting it to Linux.  Most of what's needed for the
page_aops functions for the page cache is contained in this code.
This code is currently written in Windows 2000-ease -- we are 
re-doing this code for Linux 2.4.  This work will be completed
over the weekend (I am almost finished porting it as I write
this).  The readpage, writepage, bmap, etc. functions are 
currently commented out in the 2.4 build until this code module
has been ported to Linux.

The build on 2.4 is fully functional with the aforementioned
restrictions.  NWFS 2.2.2 builds on Linux Kernels 2.0 and 2.2
are unaffected and nearing code and feature completion.


BUILDING NWFS
-------------

The globals.h file contains the following table of options:

#define  WINDOWS_NT_RO    0
#define  WINDOWS_NT       0
#define  WINDOWS_NT_UTIL  0
#define  WINDOWS_CONVERT  0
#define  WINDOWS_98_UTIL  0
#define  LINUX_20         0
#define  LINUX_22         1
#define  LINUX_24         0
#define  LINUX_UTIL       0
#define  DOS_UTIL         0

The LINUX_20, LINUX_22, and LINUX_24  File System driver options are the 
only driver versions covered under this particular release.  Select
either LINUX_20, LINUX_22, or LINUX_24 and set to 1 in globals.h 
(you can only select one at a time).  

There are makefiles included for differnt kernel configurations.  To
make the NWFS driver for Linux, select one of the following.  The
makefiles support modversioned kernels and naked kernels.

make -f nwfs.mak         This will make an NWFS driver SMP-no  MODVER-no
make -f nwfsmod.mak      This will make an NWFS driver SMP-no 
MODVER-yes
make -f nwfssmp.mak      This will make an NWFS driver SMP-yes MODVER-no
make -f nwmodsmp.mak     This will make an NWFS driver SMP-yes
MODVER-yes


TO-DO-List.
-----------

The list has gotten very short, and few items remain (less platform
optimization work) for closure for NWFS on Linux relative to
providing all the features of the Native NetWare File System.
Tuning and performance work is always on-going.

2.4 Linux kernel Only.
-----------------------

1.  Complete port of NWFS VM Cache Manager for Windows NT/2000 to 
Linux to support the page cache with NWFS sematics.

2.  Fix Oops and regression test for NWFS direct I/O buffer head 
construction (BH_Mapped bit and allocate LRU memory via 
get_page(); and __free_page() API's.

3.  Integrate Windows NT/2000 VM Cache Manager Interface for NWFS
with the Linux Page Cache (when worlds collide).

4.  Finish and submit block_dev.c patch to Linux kernel folks for
disk, CDROM scanning during NWFS Init and Volume Mount.

2.0, 2.2, and 2.4 Linux Kernel Items
------------------------------------

0.  Regression test "rm -r *" directory file readdir() bug with
new fix suggested by Stephen Tweedie, Al Viro, and Petr Vandrovec
(NCPFS method for handling POSIX readdir() compliance).

1.  Implement Macintosh Data Fork Support and integrate with HFS code
on 2.2 and 2.3 for the Linux Macintosh File Service.

2.  Implement 255 character name support in the extended directory for
NFS and LONG namespaces (current is 80 character).

3.  Implement extensible parent hash skip lists for rapid positional
numeric probes of the parent hash (like readdir and lookup like to do).

4.  Add deleted block sequence number engine for salvageable file
system (rename Command needs to support -2 deleted file directory).

5.  Implement splay tree for hash buckets on name hashes instead of
linked lists for better search times.

6.  Implement hash in aio manager for rapid indexing during add io
requests.

7.  Finish Netware hard link support NetWare NFS style instead of
linux style (very ackward implementation).

8.  Implement cpu_to_le32(), etc. macros and test on IA64, Sparc64, and
Alpha64.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

From: "Jeff V. Merkey" <jmer...@timpanogas.com>
Subject: [ANNOUNCE]NWFS 2.4 Driver and Tools Source Code Released
Date: 2000/07/21
Message-ID: <linux.kernel.3978EEED.81C561DA@timpanogas.com>
X-Deja-AN: 649347945
Approved: n...@nntp-server.caltech.edu
Organization: TRG, Inc.
X-To: linux-ker...@vger.rutgers.edu
Content-Type: multipart/mixed; boundary="------------B241BA413A9935525F0F1DFE"
MIME-Version: 1.0
Newsgroups: mlist.linux.kernel


An interim release of NWFS 2.4 (NWFS0721) is available for download at
207.109.151.240 and www.timpanogas.com.  This is an interim release
version.  The page cache support for 2.4 is being reworked for
performance reasons (and to address new bugs introduced by all the VM
changes of late), so this release has it disabled until the next post on
Monday, July 24, 2000.  The name hashes are also being reworked to
support volume repair during mounting.  The source code for the tools is
also being released as of this version for MSDOS, Linux, and Windows
NT/2000, less the imaging tools and ncurses tools for imaging.  The name
hashes are being reworked to reduce the memory footprint of volumes with
multiple namespaces.

All previously reported bugs have been closed and regressed including
the MKISOFS, posix and readdir() bugs, and LRU deadlock problems. 
Another release will follow next week with page cache and auto-repair
enabled (and the hard link issue raised by Andi at Suse), and diff files
for 2.2.X and 2.4.X code trees.  There is a bug in 2.4.0 with symlinks
when you try to delete them with this version, you get an opps at line
187 in filemap.c.  Next post of NWFS will be Monday July 24, 2000.  

The tools source code is released under the GPL.  MANOS is also
available under the GPL at 207.109.151.240.

Jeff Merkey
CEO, TRG


NWFS 2.2.4 RELEASE NOTES
------------------------

NWFS is a work in progress.  TRG will continue to develop enhancements
and new features to NWFS in the future.  You are encouraged to report
bugs or requests for feature enhancements to i...@timpanogas.com

This release supports Linux Kernels 2.0 and 2.2 and 2.4.  NWFS 2.4.0
source code can be downloaded from www.timpanogas.com or FTP at
207.109.151.240.

ENHANCEMENTS
-------------

We have increased the number of disks on Linux from 32 to 325, and have 
implemented support for 128 SCSI disks, 128 I2O disks, /dev/mdXX RAID,
10 IDE controllers, Parallel Port ATA IDE Disks, and ESDI devices.  The 
NWFS Tools available at www.timpanogas.com have also been updated with
this additional disk support.  Anyone who has already purchased tools
will be getting an update over the internet with these extended 
capabilities.

We have implemented fsync, and remount capability.  NWFS 2.2.4 also
will allow a single NetWare volume to be mounted on several mount 
points at one time.  

We have implemented variable blocksize for NWFS.  Previous versions 
were hard coded to a 512-byte sector size.  NWFS will now use 512,
1024, 2048, and 4096-byte blocks.  LOGICAL_BLOCK_SIZE in GLOBALS.H 
is the variable to modify when configuring this.  

The Asynch IO manager now has implemented a double hash for faster
io insertion performance.  insertion hits average 96% efficiency 
for locating the insertion point in a single probe (1) in the double hash
with the remaining 4% of cases locating the correct insertion point in a 
single probe (1) on a list with only one other element (both cases are 
under a 1 probe operation with this implementation).  This was tested 
with a block bufer LRU with 6000 blocks.

Since on 2.4, the page cache does the I/O for file systems, the LRU block 
cache in NWFS no longer needs to cache data blocks for file system I/O, just
directory and fat blocks, which control the meta-data for NWFS.  As such,
it would be reasonably anticipated that A) The LRU max blocks value should
be reduced in 2.4 since we don't need as much memory to cache data blocks
for files, and B) since the entire LRU will be available exclusively for
fat and directory blocks in NWFS, this should make NWFS performance on Linux
very good since most of a volumes meta-data will be able to stay in LRU cache
memory for readdir(), lookup(), create(), unlink() operations, etc.  
 
To increase the caching, modify MAX_VOLUME_LRU_BLOCKS under the 
appropriate Linux section of GLOBALS.H (LINUX_20, LINUX_22, or LINUX_24).
You can also increase the MAX_BUFFER_HEADS value to increase the 
window size of AIO requests.  The larger this number, the more 
buffer heads will be available to post at one time within the 
Linux elevator.  Using Linux AIO has solved many issues, including
elevator coordination issues between the NWFS LRU and the Linux
Buffer Cache.  With LINUX_AIO enabled, both the Linux buffer cache
and the NWFS LRU exploit the elevator logic in the block device 
layer, and this almost completely eliminates disk thrashing when
copying from buffer cache file systems and NWFS.

On 2.2.15, if you feed too many AIO requests at one time (over 500), 
in some testing cases we have seen 2.2.15 barf and lockup.  Analysis 
seems to indicate low memory conditions are the culprit here.  
2.3.99 seems to handle larger loads much better.  

I could write a book on the issues with doing asynch I/O in Linux
after this experience, suffice to say that the difficulty level is 
close to that experienced when using Windows 2000 AIO, though in
Linux you don't have to handle nested page faults delivered
through a try {} finally exception filter, so it is a much easier 
AIO implementation than on Windows 2000. :-)



BUILDING NWFS
-------------

The globals.h file contains the following table of options:

#define  WINDOWS_NT_RO    0
#define  WINDOWS_NT       0
#define  WINDOWS_NT_UTIL  0
#define  WINDOWS_CONVERT  0
#define  WINDOWS_98_UTIL  0
#define  LINUX_20         0
#define  LINUX_22         1
#define  LINUX_24         0
#define  LINUX_UTIL       0
#define  DOS_UTIL         0

select build environment (you can only select one at a time).  

There are makefiles included for different kernel configurations.  To
make the NWFS driver for Linux, select one of the following.  The
makefiles support modversioned kernels and naked kernels.

#define  LINUX_20         0
#define  LINUX_22         1
#define  LINUX_24         0

make -f nwfs.mak         This will make an NWFS driver SMP-no  MODVER-no
make -f nwfsmod.mak      This will make an NWFS driver SMP-no  MODVER-yes
make -f nwfssmp.mak      This will make an NWFS driver SMP-yes MODVER-no
make -f nwmodsmp.mak     This will make an NWFS driver SMP-yes MODVER-yes

The Linux versions are supported under the GCC Linux compiler
To make the Linux tools:

#define  LINUX_UTIL       1

make -f util.mak


The DOS versions are supported under the DJ Delorie GCC MS-DOS compiler.
To make the MS-DOS tools:

#define  DOS_UTIL       1

make -f util.mak

The Windows NT/2000 versions are supported under Microsoft C++ 5.0 or higher
To make the WIndows NT/2000 tools:

#define  WINDOWS_NT_UTIL       1

nmake /f utilms.mak


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

From: "Jeff V. Merkey" <jmer...@timpanogas.com>
Subject: [ANNOUNCE] NWFS 2.4.2 File System and Tools Source Code Released
Date: 2000/08/01
Message-ID: <linux.kernel.398750D8.ADB8C79E@timpanogas.com>
X-Deja-AN: 653418101
Approved: n...@nntp-server.caltech.edu
Organization: TRG, Inc.
X-To: linux-ker...@vger.rutgers.edu
Content-Type: multipart/mixed
MIME-Version: 1.0
Newsgroups: mlist.linux.kernel


NWFS 2.4.2 is available at 207.109.151.240.  This release fixes bugs
reported last week with permissions and adds implements notify_change()
to get arund the kupdate problems with write_inode().  This release is
has also been brought current with Linux 2.4.0-test5 changes.

Jeff Merkey
CEO, TRG


NWFS 2.4.2 RELEASE NOTES
------------------------

NWFS is a work in progress.  TRG will continue to develop enhancements
and new features to NWFS in the future.  You are encouraged to report
bugs or requests for feature enhancements to jmer...@timpanogas.com

This release supports Linux Kernels 2.0 and 2.2 and 2.4.  NWFS 2.4.2
source code can be downloaded from www.timpanogas.com or FTP at
207.109.151.240.

This is an interim release that contains bug fixes.  The next major 
release (2.5) uses a rapid mounting scheme with a journal that allows
NetWare volumes to be mounted rapidly and demand-paged rather than
needing to read the entire volume directory and name hashes into memory.  
The 2.5 version reduces memory usage to @ 1/80th of what we are using 
at present.   2.5 also supports files up to 256 tera-bytes in size 
depending on the OS architecture (Linux looks like 16 TB max).

ENHANCEMENTS
-------------

This Release adds notify_change() support and corrects permissions problems
and blocksize problem bug reports and problems with permissions 
getting lost by kupdate bugs.  NWFS originally had only implemented 
write_inode() instead of notify_change() [which the docs state 
is the fall-through case for notify_change()], however, there
appears to be some holes in the VFS where permissions can get
lost if notify_change() in not instrumented.  

This release of the tools code will also force partition alignment when 
partitions are created under Linux with the NWFS Tools.

NetWare will always allocate the first partition on a device to start 
on 0 + SectorsPerTrack, which may not be block aligned with the 
defined block sizes in Linux.  NWFS allows partitions that are not 
block aligned to be read, but only if LOGICAL_BLOCK_SIZE is set to 512 
byte blocks.  This can cause conflicts with some Linux filesystems 
(like EXT2) that by default use a block size of 1024.  

The tools will create partitions aligned on cylinder boundries 
to allow NWFS on Linux to use any Linux block size selections 
between 512, 1024, 2048, and 4096. However, on NetWare partitions 
created by Native NetWare, you may need to set LOGICAL_BLOCK_SIZE 
in the NWFS driver to 512 if you want to read NetWare partitions 
created by NetWare that may have been created on a non-block 
aligned boundry using the SPT method. If you are migrating NetWare
volumes to Linux, or plan to use NWFS volumes created under Linux 
on NetWare, you will want to set the TRUE_NETWARE_MODE flag in 
globals.h and build NWCONFIG and the tools with this setting so 
partitions will use the SPT method rather than cylinder aligning
the partitions.  If this flag is set, the LOGICAL_BLOCK_SIZE will
default to 512 so the NWFS driver can read these partitions since 
they may not be block-aligned the way Linux wants to see them.

NetWare supports variable length sector requests, so this concept 
of hard coded block sizes is alien to NetWare.  

Also, some folks reported seeing noisy messages in the /var/log/messages
file:

modprobe--can't locate module block-major-13
modprobe--can't locate module block-major-47
modprobe--can't locate module block-major-13
modprobe--can't locate module block-major-47

NWFS has to scan all the devices reported on the gendisk_head to build
a segmentation and mirroring map of devices on the system since NetWare
volumes can be mirrored or multi-segmented and span disks, and I 
have to probe for minor devices and attempt to open them all.  Linux will
report on some systems that devices are present when they are not.
THe message is generated from blkdev_open when I attempt to open
one of these devices -- the messages are benign and 'noisy', so 
ignore them.

This release is current with Linux 2.4 as of 2.4.0-test5.  The 
additional parameters to write_inode(, int wait) and changes to the 
timer_list structure and dentry structures have been updated, along 
with the change to support the b_private field in the buffer_head 
structure rather than the b_dev_id field.  We also have added
the cleanup calls for kmem_cache_destroy() for 2.4.  The BUG() at line 
186, filemap.c problem is not fixed as of this release if you 
attempt to remove symbolic links from an NWFS volume under 
Linux 2.4.0-test5


BUILDING NWFS
-------------

The globals.h file contains the following table of options:

#define  WINDOWS_NT_RO    0
#define  WINDOWS_NT       0
#define  WINDOWS_NT_UTIL  0
#define  WINDOWS_CONVERT  0
#define  WINDOWS_98_UTIL  0
#define  LINUX_20         0
#define  LINUX_22         1
#define  LINUX_24         0
#define  LINUX_UTIL       0
#define  DOS_UTIL         0

select build environment (you can only select one at a time).  

There are makefiles included for different kernel configurations.  To
make the NWFS driver for Linux, select one of the following.  The
makefiles support modversioned kernels and naked kernels.

#define  LINUX_20         0
#define  LINUX_22         1
#define  LINUX_24         0

make -f nwfs.mak         This will make an NWFS driver SMP-no  MODVER-no
make -f nwfsmod.mak      This will make an NWFS driver SMP-no  MODVER-yes
make -f nwfssmp.mak      This will make an NWFS driver SMP-yes MODVER-no
make -f nwmodsmp.mak     This will make an NWFS driver SMP-yes MODVER-yes

The Linux versions are supported under the GCC Linux compiler
To make the Linux tools:

#define  LINUX_UTIL       1

make -f util.mak


The DOS versions are supported under the DJ Delorie GCC MS-DOS compiler.
To make the MS-DOS tools:

#define  DOS_UTIL       1

make -f util.mak

The Windows NT/2000 versions are supported under Microsoft C++ 5.0 or higher
To make the WIndows NT/2000 tools:

#define  WINDOWS_NT_UTIL       1

nmake /f utilms.mak


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/







From: jmer...@timpanogas.com (Jeff V. Merkey)
Subject: [ANNOUNCE] NWFS 2.4.3 NetWare Driver and Tools Sources Released
Date: 2000/08/03
Message-ID: <3988C92F.99A84797@timpanogas.com>#1/1
X-Deja-AN: 653834792
Sender: owner-linux-ker...@vger.rutgers.edu
Organization: TRG, Inc.
X-Accept-Language: en
Content-Type: multipart/mixed
MIME-Version: 1.0
Newsgroups: linux.dev.kernel
X-Loop: majord...@vger.rutgers.edu


This is an interim release of NWFS 2.4 that contains bug fixes and
performance enhancements.

The driver and config tools source code for NWFS version 2.4.3 is
available for download at 207.109.151.240 and www.timpanogas.com.  This
version corrects problems in the rename() function not zapping target
files and a file corruption problem with the TurboFAT Indexes reported
by Steven Hirsch. There is still a problem on 2.4-test5 with symlinks in
filemap.c, line 189 BUG().    Will ry to have a fix up tommorrow
afternoon.

I am still seeing the following linker misbehavior while linking and
building the linux 2.2.16 and 2.4.0-test5 source trees on a live NWFS
Volume, but is goes away if you simply type 'make bzImage' over again
and the make picks up where it left off.  I am still tuning the page
cache interface, so I suspect the problem may lie there or I need to
release 2.5 as soon as possible with rapid mounting (which does not use
the memory intensive name hashes) ...:

BUG IN DYNAMIC LINKER:  ld.so: rtld.c 601: dl_main:  Assertion
'_dl_rtld_map.l_libname' failed.

Jeff Merkey
CEO, TRG


NWFS 2.4.3 RELEASE NOTES
------------------------

NWFS is a work in progress.  TRG will continue to develop enhancements
and new features to NWFS in the future.  You are encouraged to report
bugs or requests for feature enhancements to jmer...@timpanogas.com

This release supports Linux Kernels 2.0 and 2.2 and 2.4.  NWFS 2.4.3
source code can be downloaded from www.timpanogas.com or FTP at
207.109.151.240.

This is an interim release that contains bug fixes.  The next major 
release (2.5) uses a rapid mounting scheme with a journal that allows
NetWare volumes to be mounted rapidly and demand-paged rather than
needing to read the entire volume directory and name hashes into memory.  
The 2.5 version reduces memory usage to @ 1/80th of what we are using 
at present.   2.5 also supports files up to 256 tera-bytes in size 
depending on the OS architecture (Linux looks like 1TB max).

ENHANCEMENTS
-------------

This release corrects a bug in the TurboFAT indexes that could cause file 
corruption.  TurboFAT's keep a sliding pointer into the FAT chains of an
NWFS volume for rapid sequential file access.  This index stores the cluster 
offset and index last used by a read, write, or truncate to a fat chain.  There
was one case where a hash element could get reused with a stale TurboFAT
index that pointed to the previous file's fat chain.  This bug has been
corrected.

This release also corrects a bug in the rename() function.  This function 
was coded to exhibit NetWare behavior, i.e. when a target file exists 
under NetWare and rename is attempted, the rename fails with a 
'File Exists" return code.  Linux expects that the VFS above will have 
already done these checks, and assumes the underlying FS will simply 
delete a rename target if it already exsits.  The NWFS Linux VFS functions
in create.c have been changed to reproduce this Linux specific behavior.

The bit search lists and volume segment allocators have been optimized
to reduce bit list searching to under a dozen or so probes while looking
for free suballocation blocks or clusters on a NetWare volume.  This 
optimization allows for very fast bit block search times even on 
extremely large multi-segmented NetWare volumes.  

The suballocation FAT chains also have been enabled to use TurboFAT
indexing to speed suballoc read and write operations.

We will attempt to post the page cache code and a fix for the symlink
problem on 2.4.0-test5 tommorrow.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

			  SCO's Case Against IBM

November 12, 2003 - Jed Boal from Eyewitness News KSL 5 TV provides an
overview on SCO's case against IBM. Darl McBride, SCO's president and CEO,
talks about the lawsuit's impact and attacks. Jason Holt, student and 
Linux user, talks about the benefits of code availability and the merits 
of the SCO vs IBM lawsuit. See SCO vs IBM.

Note: The materials and information included in these Web pages are not to
be used for any other purpose other than private study, research, review
or criticism.