Return to BSD News archive
Xref: sserve comp.sys.ibm.pc.hardware.storage:13501 comp.periphs.scsi:26466 comp.sys.next.hardware:13614 comp.os.linux.misc:29357 comp.os.linux.help:64687 comp.os.386bsd.misc:4039 comp.os.386bsd.questions:14354 Path: sserve!newshost.anu.edu.au!harbinger.cc.monash.edu.au!bunyip.cc.uq.oz.au!munnari.oz.au!constellation!news.uoknor.edu!ns1.nodak.edu!netnews.nwnet.net!news.clark.edu!spool.mu.edu!howland.reston.ans.net!gatech!udel!news.mathworks.com!yeshua.marcam.com!charnel.ecst.csuchico.edu!xmission!news.cc.utah.edu!cs.weber.edu!terry From: terry@cs.weber.edu (Terry Lambert) Newsgroups: comp.sys.ibm.pc.hardware.storage,comp.periphs.scsi,comp.sys.next.hardware,comp.os.linux.misc,comp.os.linux.help,comp.os.386bsd.misc,comp.os.386bsd.questions Subject: Re: SyQuest SQ3270S for Data Exchange? Date: 7 Nov 1994 21:33:05 GMT Organization: Weber State University, Ogden, UT Lines: 105 Message-ID: <39m6eh$hts@news.cc.utah.edu> References: <CyrtGF.2u4@prz.tu-berlin.de> NNTP-Posting-Host: cs.weber.edu In article <CyrtGF.2u4@prz.tu-berlin.de> wolf@prz.tu-berlin.de (Thomas Wolfram) writes: ] I would like to use my SyQuest SQ3270S, i.e. the cartridges, ] for exchanging data. Sounds natural but what happens if ] different SCSI controllers in the different computers are ] using different heads/sectors translation schemes (e.g. ] Adaptec controllers make every SCSI disk to appear to have ] 64 heads and 32 sectors, but not all SCSI controllers ] do the same) and this information is stored in any way in ] the respective partition when it's formatted? The quick answer is "it depends". The longer answer is "it depends on if the translation is linear". If the translation is linear, then there is a 1:1 correspondence between sectors, in order, in both translated and untranslated modes. That is, if you multiply out the CHS value to get the absolute sector address, then the absolute sector address contains the same data as if you had done an untranslated access. Protected mode operating systems (in general, anyway) don't do BIOS access and are thus always untranslated. In general, unless the controller is "too smart" and reserves sectors to do controller/BIOS based bad sector forwarding (like some WD1007 ESDI controllers) in the middle of the disk, then the translation is totally irrelevant. Or rather, it is relevent only if the media is supposed to be considered bootable. ] Even DOS stores the number of heads ] and sectors in the "boot" sector of the respective ] partition. Does this cause any problems when using the ] cartridges in different computers? Only if they are bootable (see above). ] What about the BSD file system of NeXTSTEP? Is exchanging ] cartridges possible? It's possible -- if you write a NeXTStep "BSD FS" for BSD, or a BSD "BSD FS" for NeXTStep. It's easier if you use the media as a linearly addressable media -- and then just tar directly to and from the raw device. Making the device cross-mountable between operating system types is a non-trivial task, especially if you are missing source for one of those operating systems. This becomes more difficult (byte order problems and access alignment problems, etc.) if you are trying to move the media between machines with different processer architectures. ] What about the Linux file system? Linux and *BSD could easily cross-mount each other's file systems; as a developement environment, FreeBSD 2.0/NetBSD 1.0 are probably better choices for implemented an ext2fs or other Linux FS, although porting the BSD FS into Linux would probably be pretty trivial as well as long as you were very familiar with the VM system on Linux and started with older FS code (the OS consumer interface in the newer *BSD versions is vnode rather than VM based and is thus much harder to port into the older Linux VM consumer model). One (gross) alternative might be to format the media and mount it using an FS that is already supported by your platforms: MSDOSFS. The problems in doing this are a loss of long names and a loss of POSIX FS compliance (an MSDOS FS can only comply with POSIX if it is mounted read-only). You should be aware that Linux, if you choose it as a platform, has some cache code discrepancies that I don't quite trust when it comes to removable media. It doesn't flush the cache on a removable volume's data when the volume is removed. There is a finite probability for error in doing this. This is not as much of a problem in CDROMs, but for writable media it could quickly become a problem. The tagging mechanism is similar to IBMs JFS, which (incorrectly) assumes that a removable volume will be remounted in the same drive it was first created in. Multiple drives will drive it nuts, since it assumes the drive idenitifier as part of the unique ID for the volume. This is especially evident if you are trying to do CD mastering with a R/W ISO9660 volume and a CDROM one-off and both are on removable media. The easiest correction is to modify the Linux FS code to invalidate the vnode cache for the device when the device is unmounted. I'm told that this has been suggested to the Linux folks in the past, but that there are remount performance considerations that they don't want to degrade. Anyone with two or more removable devices of any kind, or anyone with a single writeable removable device should apply the correction without regard for the opinions of "the powers that be". Remount isn't that frequent unless you are running a CDROM jukebox anyway. Regards, Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers.