Alan,
I guess since my brain is 40+ years old and dying, I will keep getting
slower... and slower ..... integrating this into a release is about
4 times the work I had thought (GNU partspec -- what is mess!!!). 2.4
seems to have stopped changing and is very stable, and Linus appears
to have stopped playing in it so I am motivated to add this now for
a 2.4 release since 2.4 is so stable. I have had to do some things
to get around the inode mapping problem to work with Linux that really
makes native NetWare stand on it's head.
What I've done to support true Linux hard links and static inode
numbers is to simply backlink changed records within a 4K directory
block to the new parent. Oddly, there were some cases that would
make Native NetWare break when it saw this, but I have tested this
change now for about two months with every rev from 3.x through 5.x
NetWare, and have identified the cases where I need to recreate
directory entries and move the file entries to a new block vs.
just backlink them. As it turns out, I can safely backlink any
regular files, thereby preserving the directory relative number in
the dir file I use as a static inode number. This was an extremely
complex problem that required an enormous testing effort, since
NetWare always assumes all entries within a single 4K block are
owned by the same parent. There were cases in the NFS server where
this was allowed to happen to support NFS on NetWare, and it is
this behavior that I am exploiting. As it turns our the only place I
have to move directory entries is when I move deleted files to
the DELETED.SAV directory, which Linux is totally ignorant of
in any event -- they just show up as new files, which is
OK (it's not an implied mv (rename) operation since deleted
files from a linux perspective are expected to disappear
from a volume).
I also eliminated all the in memory name hases except for the the root
DOS namespace and reduced memory usage by a factor of 10, and implemented
the extended directory for 255 > character names.
I have modified anaconda to install NWFS partitions and am working on
Unix-like fsck.nwfs and mkfs.nwfs tools. I've had to do some things
the linux way to get this working correctly. Some issue, questions,
need guidance stuff for the merge of this code.
A). NWFS doesn't use the "rule of 1" (1 partition - 1 file system) and
can stripe volumes, mirror volumes, etc.
B). In order to make install and most of the linux tools work properly,
I have to provide this "rule of 1" behavior.
So there is a limitation for installing and using multi-segmented NWFS
volumes on Linux for root filesystems, what I have done is set the
default behavior to this:
mkfs.nwfs /dev/hda SYS
just like the linux tools behave with ext2, however, this will always
limit a root volume to one NetWare volume segment on one Linux partition,
and it should probably always by named "SYS" if it's the root, so MARS will
be able to provide default NetWare behavior. This tool also allows
NetWare volumes to be created in these funky Linux extended partitions
with a "rule of 1" behavior.
If people want to configure stripping, mirroring, multi-segmented volumes,
or if they want to dynamically add segments to live root NWFS volumes,
The NWCONFIG tools let them do this after the fact or install. If
existing NetWare volumes exist on the server, I have modified the
anaconda installer to look for SYS, and use it as the root volume
for the linux install.
I made fsck.nwfs a little smarter, and it can repair stripped and mirrored
volumes as well as these "linux clone" netware volumes on extended
partitions.
questions:
1. Do I tar.gz the nwfs tools source base, and post as nwfs-utils.tar.gz
separate from the patch, and will these be posted with the ext2 tools?
Are you ready if I post NWFS to merge 2.2.18 patches?
2. Will a 2.4 patch for NWFS be accepted this close to release. It only
adds some config options and it'w own atomic code. High and low water
marks to adjust LRU memory usage key off variables in the OS, and I have
not needed to put in any patches to standard code -- I even got around the
512 buffer head thing.
Jeff