Date: Mon, 29 Jan 2001 13:44:59 -0700 (MST) From: Eric Lee Green <eric@estinc.com> To: Matthew Jacob <mjacob@feral.com> Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: Persistent block size? Message-ID: <Pine.LNX.4.21.0101291323400.27133-100000@h23.estsatnet> In-Reply-To: <Pine.LNX.4.21.0101291025430.21978-100000@zeppo.feral.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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".
> > 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.
> > 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).
> 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).
--
Eric Lee Green eric@estinc.com
Software Engineer "The BRU Guys"
Enhanced Software Technologies, Inc. http://www.estinc.com/
(602) 470-1115 voice (602) 470-1116 fax
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.LNX.4.21.0101291323400.27133-100000>