fangchin@elaine41.stanford.edu (Chin Fang) (11/28/90)
Hi everyone,
After I saw the posting from Jeff of ESIX tech support, I immediately decided
to give it a try. The following are a list of problems that I have encoutered
and some new discoveries that I have found along the way. Before I go on,
I would like to invite other ESIX users sharing your experience. If anyone
has succeded, please post.
My motivation is very simple, Stanford's unix machines are all Berkeley type,
so every now and then when I do file (src in particular), you can imagine my
trouble of shortening file names.
First, problems:
1. the -sysv switch no longer the controlling switch for SysV format or
Berkeley long file name format (255 char.) Another ESIX user Mr. Yergeau
of EE Department also found that out and informed me too.
2. The controlling switch turns out to be the -S switch for /etc/ffs/mkfs.
The way to tell is invoking /etc/ffs/newfs -v -N /dev/rdsk/0s0 and you
will immediately see /etc/ffs/mkfs -S -N -R 4 even though in release notes
and the usuage output from newfs to stdout /etc/ffs/mkfs is mentioned as
default, it IS NOT!
3. I don't see a way to prevent /etc/ffs/newfs from invoking /etc/ffs/mkfs
without the -S switch.
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.
5. Using back up floppies thus created, I could finish the first two floppies
without any symptoms. However, after prompted reboot the system, I didn't
get the familar "Are you installing from tape" prompt, instead, my machine
kept booting itself after each memory parity check. I did once quick
recovery reinstallation, NO use!
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).
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
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.
Well, I pretty much said my discoveries in the problem section. So I will stop
here. I am out of ideas to try now. It would be very helpful if people who
have rebuilt the true Berkeley FFS on their primary hds come out and share
their experience. I hope the above info could be useful if no one have ever
attempted so far. I also would like to acknowledge three persons for their
info: Mr. Dan Yergeau of Stanford's EE Department, he gave me most of the hints
Jeff Eliss and Jeff Row of ESIX Tech Support, their info is out of date
but their friendly and helpful attatitude never changes.
Chin Fang
Mechanical Engineering Department
Stanford University
fangchin@portia.stanford.edumburg@unix386.Convergent.COM (Mike Burg) (11/29/90)
In article <1990Nov28.061825.4352@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