Date: Mon, 29 Jan 2001 15:56:26 -0800 (PST) From: Matthew Jacob <mjacob@feral.com> To: Eric Lee Green <eric@estinc.com> Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: Persistent block size? Message-ID: <Pine.BSF.4.21.0101291553230.23423-100000@beppo.feral.com> In-Reply-To: <Pine.LNX.4.21.0101291323400.27133-100000@h23.estsatnet>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 29 Jan 2001, Eric Lee Green wrote:
> On Mon, 29 Jan 2001, Matthew Jacob wrote:
> > On Mon, 29 Jan 2001, Eric Lee Green wrote:
> > > Trying to figure this one out. 'mt -f /dev/sa0.ctl' does not give the
> > > expected result ('mt' carps that it can't do it),
> >
> > You have to be a bit more prescise than 'mt carps'.
>
> Sorry. 'mt' reports "Invalid parameter".
More details than this (like, the command line you're using)
>
> > > but reading the source,
> > > it looks like it should work. Anybody know whether it's 'mt' that's
> > > busted, 'sa.c', or simply a misguided notion in my head that the .ctl
> > > device is used to set persistent parameters (i.e., parameters that last
> > > longer than a session)?
> >
> > Hmm??? If a tape hasn't been mounted yet, i.e. read or accessed, it's quite
> > possible that paramaters aren't known, are they?
>
> Err, I was trying to set a default block size that lasted longer than a
> mount session. It seemed to me that it ought to be possible, but reading
> the 'mtio' and 'sa' documentation, it wasn't clear how. The thought in my
> head (obviously misguided :-) was that setting the parameter via the .ctl
> device would make it persist (as vs. setting it on the /dev/nsa0 device,
> where quite obviously it goes away until the next mount session).
>
> > The purpose of the .ctl device is mostly to be able to access the device when
> > somebody has the regular device open. The man page may need updating.
>
> Ah. That clarifies things.
>
> > What do you mean by 'persistent' parameters? Held across multiple mount
> > sessions, or permanent across reboots?
>
> Held across multiple mount sessions. Having to set the block size back to
> zero every time I insert a tape is a nuisance, though not a big one
> because I only have to do that when I'm checking the tape format of
> various tapes with 'mt' and 'dd' to see whether I've achieved
> cross-platform commonality (sigh). As mentioned before, the backup
> software itself handles that in actual production, so it's no biggie and
> doesn't affect my software. Just that I've had that ability on The OS
> That Shall Not Be Mentioned, and missed it on FreeBSD.
Hmm.
>
> > > At the moment I'm just saying "%#@! it", since my storage manager resets
> > > the block size anyhow within a session (so non-persistence doesn't affect
> > > my backup software anyhow)... but that doesn't solve the problem of me
> > > being curious :-}.
> >
> > Did you unmount the tape? That will probably clear things.
>
> ??? (Puzzled).
You said as much above.
>
>
> > Sounds like an RFE is in the works here. Jeez, between you and Jean-Francois,
> > it looks like I'll really have to fix things I've been putting off.
>
> Well, I can think of several things I'd put into an RFE, such as
> cross-session-persistent default parameters, but right now I'm too busy
> thinking gloomily about Solaris. (Their tape ioctl is totally worthless
> for our purposes, meaning that we had to basically write a new tape driver
> that issues raw SCSI commands for reading and writing data on tape... how
> the BLEEP these guys got to be #1 in front of people like SGI that have a
> sane OS baffles me).
Well, I wrote the original Solaris tape driver back in 1990 or so (derived
from SunOS 4.0.3c's tape driver) so you can complain to me. Hell, I might even
be able find the current maintainer for you to talk directly with.
You think IRIX is sane? Too much uncapped glue in your apartment, friend...
-matt
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-scsi" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0101291553230.23423-100000>