The Open Source Code for NWFS 2.2.1 hss been posted to
www.timpanogas.com and 207.109.151.240. This version corrects a
reported mirroring coalescence problem and fixes a bug in the
nwvp_vpartition_map_asynch_write() function.
NWFS 2.2.1 Sources are in the nwfs0328.zip and nwfs0328.tar.gz files on
our FTP server at 207.109.151.240 or www.timpanogas.com. We will post
NWFS 2.2 for Linux Kernel 2.4 support tommorrow morning at 7:00 a.m.
Jeff Merkey
CEO, TRG
NWFS 2.2.1 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 info@timpanogas.com
This release supports Linux Kernels 2.0 and 2.2. 2.3 support will be
released Wednesday, March 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
----****************************************************************************
UPDATE: There was a bug in the LRU code for handling concurrent mirrored writes and another bug in nwvp_vpartition_map_asynch_write(). The bug would disallow immediate writes to any out of sync partitions that we being remirrored.
*****************************************************************************
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.
****************************************************************************
UPDATE: We have the info on what's going on here with the rm -r bug. GLIB has some problems with it's interaction with the dcache, and basically, the FS driver needs to keep dcache entries pinned for some types of operations when GLIB is calling readdir to enumerate directories. We are implementing a more agressive dentry interface with our own pool of dcache elements.
*****************************************************************************
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 jmerkey@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 majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Mar 31 2000 - 21:00:23 EST