dab@cbnewsm.ATT.COM (david.a.berk) (11/09/89)
1) I'm contemplating buying a Perstore Hard Disk Controller which is supposed to increase my hard disk capacity by a factor of 1.9. Does anyone have any advise or experiences using this board with AT&T System V.3.2 Unix ? (Perstore informed me that it has been tested on Interactive Unix and runs well). 2) I bought a 60 meg Tape Backup unit from Bell Tech. about a year ago. Can the AT&T Tape Backup read from a Intel Tape and vica versa. 3. Can the 6386 read a floppy witten by a 3b2 ? ..!att!emdbl1!dab Dave Berk
psfales@cbnewsc.ATT.COM (Peter Fales) (11/09/89)
In article <6358@cbnewsm.ATT.COM>, dab@cbnewsm.ATT.COM (david.a.berk) writes: > 3. Can the 6386 read a floppy witten by a 3b2 ? I you mean mount a floppy with 3b2 file system, the answer is no. However, I have transferred cpio archives written to the raw floppy in both directions between a 3b2 and 6386 WGS. Use /dev/rdsk/f05qt. -- Peter Fales AT&T, Room 5B-420 N9IYJ 2000 N. Naperville Rd. UUCP: ...att!peter.fales Naperville, IL 60566 Domain: peter.fales@att.com work: (312) 979-8031
akcs.larry@nstar.UUCP (Larry Snyder) (11/09/89)
>1) I'm contemplating buying a Perstore Hard Disk Controller which is > supposed to increase my hard disk capacity by a factor of 1.9. > Does anyone have any advise or experiences using this board with This board is slow - much slower than the 1:1 and 1:2 family of controllers. I would rather have the speed of a fast controller than the space :)
fmcgee@cuuxb.ATT.COM (~XT6561110~Frank McGee~C23~L25~6326~) (11/10/89)
In article <6358@cbnewsm.ATT.COM> dab@cbnewsm.ATT.COM (david.a.berk) writes: >1) I'm contemplating buying a Perstore Hard Disk Controller which is > supposed to increase my hard disk capacity by a factor of 1.9. > Does anyone have any advise or experiences using this board with > AT&T System V.3.2 Unix ? (Perstore informed me that it has been > tested on Interactive Unix and runs well). You'll need a Unix disk driver for the Perstore controller; AT&T doesn't provide this. The exception would be if the controller was hardware compatible with a Western Digital ST506 or ESDI controller. Notice my emphasis on hardware compatibility, not software. Since Unix doesn't use the ROM BIOS, BIOS extensions (ie, a ROM that makes the controller look like a Western Digital) doesn't buy you anything. It has to look like a Western Digital without the use of any ROM BIOS extensions. Also, the AT&T boot floppies won't recognize it since they don't know about Perstore controllers. >2) I bought a 60 meg Tape Backup unit from Bell Tech. about a year ago. > Can the AT&T Tape Backup read from a Intel Tape and vica versa. If you are running under Unix, the Bell Tech unit should be portable with AT&T units. Be carefull of media incompatibilities; it's a good idea to make sure all your drives use the same density. This is because although a 120/125 MB tape drive can read a 60 MB tape, it can't write a 60 MB tape. So if you have one machine with a 120 MB unit and one with a 60 MB unit, you can't transfer data from the 120 MB machine to the 60 MB machine (although you can go the other way). >3. Can the 6386 read a floppy witten by a 3b2 ? File systems - no (byte ordering). cpio archives - yes, if you use the -c (ascii header compatibility option). The proper device nodes for 3B floppies on 386 unix are suffixed with "5qt" (for example /dev/dsk/f05qt or /dev/rdsk/f05qt). Hope this answers your question, -- Frank McGee, AT&T Tier 3 Indirect Channel Sales Support attmail!fmcgee
gerry@zds-ux.UUCP (Gerry Gleason) (11/11/89)
In article <4615@cbnewsc.ATT.COM> psfales@cbnewsc.ATT.COM (Peter Fales) writes: >In article <6358@cbnewsm.ATT.COM>, dab@cbnewsm.ATT.COM (david.a.berk) writes: >> 3. Can the 6386 read a floppy witten by a 3b2 ? >I you mean mount a floppy with 3b2 file system, the answer is no. However, >I have transferred cpio archives written to the raw floppy in both >directions between a 3b2 and 6386 WGS. Use /dev/rdsk/f05qt. Wait a minute, if you can read the physical format, you should be able to mount it. Isn't a System V file system a System V file system (with the possible exception of version skews). What gives? Gerry Gleason
rick@pcrat.uucp (Rick Richardson) (11/11/89)
In article <16@zds-ux.UUCP> gerry@zds-ux.UUCP (Gerry Gleason) writes: >Wait a minute, if you can read the physical format, you should be able to >mount it. Isn't a System V file system a System V file system (with the >possible exception of version skews). > >What gives? Byte order isn't specified and structure padding in "struct filsys" (the superblock) will nail you. The following *GROSS HACK* I wrote to convert SVR2 floppy filesystems under Venix System V/286 to and from UNIX/386 Release 3.2 filesystems under 386/ix. I didn't have to contend with byte order, but I did have to deal with structure padding. Also note that the on disk free list of Venix is different, too. In my kludge I ignored it, since fsck will rebuild the freelist. People interested in converting filesystems can use this program to give them an idea of what the problem is. I urge you, however, to throw this one away and perhaps think of a cleaner method. My only excuse was that I was in a hurry -- I archive all comp.sources from the 286 unto mountable floppies, the 286 was down, and I needed to get some source code from the floppies onto the 386. -Rick #! /bin/sh # This is a shell archive, meaning: # 1. Remove everything above the #! /bin/sh line. # 2. Save the resulting text in a file. # 3. Execute the file with /bin/sh (not csh) to create: # fs2s5.c # This archive created: Sat Nov 11 08:14:54 1989 export PATH; PATH=/bin:/usr/bin:$PATH if test -f 'fs2s5.c' then echo shar: "will not over-write existing file 'fs2s5.c'" else sed 's/^X//' << \SHAR_EOF > 'fs2s5.c' X#include <stdio.h> X Xchar buf[512]; Xchar buf2[512]; Xlong zero = 0; Xlong clean = 0x7c269d38L; Xint fd; X Xmain() X{ X X fd = open("/dev/fh0", 2); X lseek(fd, 512L, 0); X read(fd, buf, 512); X if (buf[2] == 0 && buf[3] == 0) X { X printf("Converting to Venix Filesystem\n"); X memcpy(&buf2[0], &buf[0], 2); X X memcpy(&buf2[2], &buf[4], 4); X X memcpy(&buf2[6], &buf[8], 2); X X memcpy(&buf2[8], &buf[12], 200); X X memcpy(&buf2[208], &buf[212], 2); X X memcpy(&buf2[210], &buf[214], 200); X X memcpy(&buf2[410], &buf[414], 1); X X memcpy(&buf2[411], &buf[415], 1); X X memcpy(&buf2[412], &buf[416], 1); X X memcpy(&buf2[413], &buf[417], 1); X X memcpy(&buf2[414], &buf[420], 4); X X memcpy(&buf2[418], &buf[424], 8); X X memcpy(&buf2[426], &buf[432], 4); X X memcpy(&buf2[430], &buf[436], 2); X X memcpy(&buf2[432], &buf[438], 6); X X memcpy(&buf2[438], &buf[444], 6); X X memcpy(&buf2[504], &buf[504], 4); X memcpy(&buf2[508], &buf[508], 4); X } X else X { X printf("Converting to 386/ix Filesystem\n"); X memcpy(&buf2[0], &buf[0], 2); X memcpy(&buf2[2], &zero, 2); X X memcpy(&buf2[4], &buf[2], 4); X X memcpy(&buf2[8], &buf[6], 2); X memcpy(&buf2[10], &zero, 2); X X memcpy(&buf2[12], &buf[8], 200); X X memcpy(&buf2[212], &buf[208], 2); X X memcpy(&buf2[214], &buf[210], 200); X X memcpy(&buf2[414], &buf[410], 1); X X memcpy(&buf2[415], &buf[411], 1); X X memcpy(&buf2[416], &buf[412], 1); X X memcpy(&buf2[417], &buf[413], 1); X memcpy(&buf2[418], &zero, 2); X X memcpy(&buf2[420], &buf[414], 4); X X memcpy(&buf2[424], &buf[418], 8); X X memcpy(&buf2[432], &buf[426], 4); X X memcpy(&buf2[436], &buf[430], 2); X X memcpy(&buf2[438], &buf[432], 6); X X memcpy(&buf2[444], &buf[438], 6); X X memcpy(&buf2[500], &clean, 4); X memcpy(&buf2[504], &buf[504], 4); X memcpy(&buf2[508], &buf[508], 4); X } X lseek(fd, 512L, 0); X write(fd, buf2, 512); X X close(fd); X X exit(0); X} X Xfreelist(slen) X{ X} SHAR_EOF fi exit 0 # End of shell archive -- Rick Richardson | Looking for FAX software for UNIX/386 ?????? mention PC Research,Inc.| WE'RE SHIPPING your uunet!pcrat!rick| Ask about FaxiX - UNIX Facsimile System (tm) FAX # (201) 389-8963 | Or JetRoff - troff postprocessor for the HP {Laser,Desk}Jet
buck@siswat.UUCP (A. Lester Buck) (11/13/89)
In article <16@zds-ux.UUCP>, gerry@zds-ux.UUCP (Gerry Gleason) writes: > Wait a minute, if you can read the physical format, you should be able to > mount it. Isn't a System V file system a System V file system (with the > possible exception of version skews). A quick look at filsys.h from various vendor's versions of System V will show that the super block format, at least, varies all over the map. Without another file system switch entry, the only way I could see to mount a foreign System V filesystem was to have a _really_ smart driver that translated requests for the super block. There might be other problems with this scheme, since I never actually tried it... -- A. Lester Buck ...!texbell!moray!siswat!buck
les@chinet.chi.il.us (Leslie Mikesell) (11/13/89)
In article <4615@cbnewsc.ATT.COM> psfales@cbnewsc.ATT.COM (Peter Fales) writes: >> 3. Can the 6386 read a floppy witten by a 3b2 ? >I you mean mount a floppy with 3b2 file system, the answer is no. However, >I have transferred cpio archives written to the raw floppy in both >directions between a 3b2 and 6386 WGS. Use /dev/rdsk/f05qt. The 3B2 uses the last track of the otherwise normal 720K format for its own purposes. Thus, transfers with other machines would be limited to archives that fit on a single disk unless you do some tricky stuff to merge the pieces. Les Mikesell les@chinet.chi.il.us
randy@chinet.chi.il.us (Randy Suess) (11/13/89)
In article <1989Nov13.145552.5367@chinet.chi.il.us> les@chinet.chi.il.us (Leslie Mikesell) writes:
]
]The 3B2 uses the last track of the otherwise normal 720K format for its
]own purposes. Thus, transfers with other machines would be limited to
]archives that fit on a single disk unless you do some tricky stuff
]to merge the pieces.
Uh, if you mean a 386 machine reading 3b2 floppies via cpio,
it works fine on multiple floppy archives. I do it all the
time. Seems cpio could care less that the last track is
bogus. How do you think your humongus $HOME directory got
transfered from the 3b2 to the 386, Les???
-randy
--
Randy Suess
randy@chinet.chi.il.usmark@cblpf.ATT.COM (Mark Horton) (11/14/89)
In article <16@zds-ux.UUCP> gerry@zds-ux.UUCP (Gerry Gleason) writes: >In article <4615@cbnewsc.ATT.COM> psfales@cbnewsc.ATT.COM (Peter Fales) writes: >>In article <6358@cbnewsm.ATT.COM>, dab@cbnewsm.ATT.COM (david.a.berk) writes: >>> 3. Can the 6386 read a floppy witten by a 3b2 ? > >>I you mean mount a floppy with 3b2 file system, the answer is no. However, >>I have transferred cpio archives written to the raw floppy in both >>directions between a 3b2 and 6386 WGS. Use /dev/rdsk/f05qt. > >Wait a minute, if you can read the physical format, you should be able to >mount it. Isn't a System V file system a System V file system (with the >possible exception of version skews). No. The System V release [123] filesystems are basically the V7 filesystem with bigger blocks. This filesystem was designed for speed and convenience of access, not portability. The superblock, directory block, and inodes are full of 16-bit and 32-bit integers. A big endian machine, like the 3B2, Sun, or Amdahl will store a 32-bit integer with the MSB first, but a little endian machine, like the VAX or 6386, will store it LSB first. We've all become spoiled by the portability of the MS DOS filesystem, which means that DOS floppies are interchangable anywhere the media can be read. This only works because DOS only works on the 80x86 family, which is all little endian. cpio -c and tar are both quite portable UNIX system interchange formats, as long as you can read the physical media. Mark