Long file names for ESIX

[Mike Burg]

In article <1990Nov28.061825.4352 at portia.Stanford.EDU> you write:
[intro and description about -sysv flag not working -  deleted]
>4. My machine, a 3 year old 20 Mhz 386 with 8 megs mem and 387, would trash
>   the boot sector of a floppy whenever I mount it to be both rw.  So what I
>   did was to use gnu emacs 18.55 reading in dd image of both the first and 2nd
>   boot disk, edit out the -sysv switch from INSTALL from the dd image of the
>   1st boot disk, and -S from the dd image of the 2nd boot disk, and then 
>   dd them back to back up floppies.

Which floppy device are you using to create the filesystem? You might want
to use the specific floppy format device (i.e. /dev/rdsk/f0q15d for a 1.2m)
instead of /dev/fd0 or /dev/rdsk/f0t. Also, make sure to use the device node
which skips the first couple of tracks. I.e. Don't use anything floppy device
node that ends with a 't' AND don't use /dev/rfd0. Both of these type names
will start at block 0, thus killing the boot blocks. Use /dev/rdsk/f0q15d
or /dev/rdsk/f0.

If you are going to modify the boot floppies, I would just go in and
mount the boot disk directly (mount /dev/dsk/f0q15d /mnt) and edit
the file directly, instead of a image dump. (vi /mnt/INSTALL). INSTALL
is a normal shell script. It's a lot easier.

[Description about problem with memory check - deleted]
>6. I installed the normal 14 char ESIX FFS, and used emacs to edit 
>   /etc/ffs/newfs on the hd, overwrote the -S switch in the binary file with
>   blanks, and tried to use it to rebuild a file system for /usr.  Either I 
>   did something wrong or other things I did not know about, the entire 
>   ESIX system installed on my hd became non-functional.  ( I got a panic and
>   memory dump  right after I did the file system manual rebuild).

Hmm... You might want to call ESIX back and ask them if they included
the FFS filesystem support in the boot loader. There is a version of the boot
loader that I modified to handle the FFS layout. Also, the srmount() function
in the kernel (this mounts the root filesystem) might not have the modification
to check for a FFS root filesystem.

> 
>7. ESIX release notes and what I found from playing with the two utilities 
>   are not totally consistent. ie. Doc says one thing, the utilities do another
>   if you poking into the binary using a binary editor or emacs, you will agree
>   with me even more.  So obviously, after Mike Bert(?  the gentleman who 
[that's a new spelling for my last name... It's Burg not Bert.]
>   implemented Berkeley FFS for ESIX and left to join Unisys not long ago) 
>   someone at ESIX must have changed the entire file system code without 
>   proper doc the mods.

More like left ESIX in Oct of '89, and then started in Unisys late summer
'90, via two short term contracting jobs and a bad 4 months at a small
software company. As I said before, it's been a while so my memory
might be a bit rusty. 

I don't think I stated exactly that the entire code changed without making
reflecting changes in the documentation. When I left, it was a few days after
the Rev C release. The original plan for Rev C was to have the FFS included.
However due to time and testing limitations, it was pushed to Rev D. The
state of the code at the time was that it was ready for the first of many
Quality Assurance Cycles and then Beta testing after that. This means
it was still rough, but working, and awaiting some kind soul to put the
finishing touches on. 

My suggestion, is *NOT* to have a ENTIRE FFS system, rather have root (/) as 
the standard System V filesystem (S51K) and and maybe /usr as FFS, and the
rest as FFS (/usr2, /usr3, etc). There maybe still some utilities that do
not make use of the opendir() mechanism
and are hardcoded for 14 character filenames. This is also true of certain C
library functions. Namely, ftw() was still using the old open(".")
read(fd, &dir, sizeof(struct dir));
business. Make sure as *not* to create more than 64K worth inodes, you
can do it, but a lot of program might screw up. The problem likes with
stat() only returns a 16bit inode number.

If you can, I'd wait until System V Release 4 comes out from
ESIX (Rev E or F? ;-)) where the BSD FFS (called ufs) has been properly
ported by AT&T and the surrounding utilities and C library functions can
handle all the "features" of that filesystems.  Yes, symbolic links and quotes
are implemented, along with 32 bit inode types unlike the current
ESIX 3.2 Rev D version. And yes, you can have all the filesystems (with
the expection of a few "special" partitions) be UFS formats.

Note: I seriously doubt that the 5.4 ufs filesystem and FFS filesystems
are compatible, even though they are based off the same 4.3BSD source. 
You'll most likely need to remake the filesystems when you upgrade.


-- 
----------------------------------
Michael Burg -  Unisys/Convergent Corp.  Unix Intel Platforms Division San Jose
Phone: (408) 456-5934 UUCP: uunet!pyramid!ctnews!unix386.Convergent.com!mburg