*BSD News Article 38257


Return to BSD News archive

Xref: sserve comp.sys.ibm.pc.hardware.storage:14044 comp.periphs.scsi:26841 comp.sys.next.hardware:13766 comp.os.linux.misc:30275 comp.os.linux.help:66847 comp.os.386bsd.misc:4186 comp.os.386bsd.questions:14618
Path: sserve!newshost.anu.edu.au!harbinger.cc.monash.edu.au!bunyip.cc.uq.oz.au!munnari.oz.au!news.Hawaii.Edu!ames!saimiri.primate.wisc.edu!caen!zip.eecs.umich.edu!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: 10 Nov 1994 22:59:58 GMT
Organization: Weber State University, Ogden, UT
Lines: 75
Message-ID: <39u8le$brk@news.cc.utah.edu>
References: <CyrtGF.2u4@prz.tu-berlin.de> <39m6eh$hts@news.cc.utah.edu> <39rphi$23o@esp22.nrl.navy.mil>
NNTP-Posting-Host: cs.weber.edu

In article <39rphi$23o@esp22.nrl.navy.mil> eric@aib.com (Eric Youngdale) writes:
] 	Huh???  This is nonsense.  If you remove a scsi disk and re-insert it,
] the disk will report UNIT_ATTENTION the next time you attempt to access it.
] The scsi disk drivers notice this, and automatically invalidate all of the
] buffers associated with the drive.

If this has been corrected after 1.1.61, then I stand corrected (and would
like the code).

It is my understanding that the cached pages are *not* flushed until they
are LRU'ed.

You can demonstrated this to yourself by mounting a CDROM, ls'ing a
directory, unmounting the CDROM, mounting it again, and ls'ing the same
directory -- and noting the drive activity.

Or you can instrument the driver and see the same thing.


] 	Inodes are automatically flushed when a device is unmounted.  This is
] because you could umount, make a new filesystem and remount, and the cached
] inodes would be incorrect.

The point I was making.  But the tagging of the FS prevents this from
happening, since the tags not matching indicates a real media change as
opposed to offlining the device.

The corruption issue is only applicable to writeable media, and then it
depends on non-Bernoulli media (IOmega does it's own tagging of the media,
and they do it correctly).

This isssue was noted by an engineer at Novell UnixWare developer support;
the particular engineer wrote the UNIX drivers for the Bernoulli drives
while working at IOmega before coming to Novell.

The (apparent) intent in doing this is to better support things like FTP
and NFS servers that export multiple entries from an optical jukebox.  I'm
guessing at the intent based on one effect of the implementation here;
sorry.

Not flushing the cache yields a *significant* performance edge on Pioneer
and other jukeboxed devices.  The mistake, as I see it, is the potential
problem for non-drive-tagged removable media that is writeable, or in
identical media images in multiple drives (the mastering case) if the
media switches drives (example: two writeable one-off drives, one disk
being mounted read-only and the other read-write, with the disks being
transposed for some reason).

There is also the issue in this case that the user space NFS implementation
opens the export directory -- and holds it open.  You have to kill the
daemon to unmount the underlying media.

Keeping the cache across media mounts resolves the jukebox-remount/NFS
export interaction issue.

] >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.
] 
] 	Irrelevant.  The drive will report UNIT_ATTENTION and the buffers
] will be flushed.
] 
] 	Non-scsi devices, such as a mitsumi, also report disk change,
] and the buffers are similarly flushed when the media is changed.

Can you explain how to NFS export multiple volumes in a jukebox otherwise?

Again, if this is already corrected, then it's probably a non-issue.


					Regards,
					Terry Lambert
					terry@cs.weber.edu
---
Any opinions in this posting are my own and not those of my present
or previous employers.