Date: Sat, 8 May 1999 00:19:36 -0500 From: Karl Denninger <karl@Denninger.Net> To: mjacob@feral.com Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: Question - Onstream SCSI Streamer Message-ID: <19990508001936.A597@Denninger.Net> In-Reply-To: <Pine.LNX.4.04.9905070907070.516-100000@feral.com>; from Matthew Jacob on Fri, May 07, 1999 at 09:17:22AM -0700 References: <19990507110558.A614@Denninger.Net> <Pine.LNX.4.04.9905070907070.516-100000@feral.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, May 07, 1999 at 09:17:22AM -0700, Matthew Jacob wrote: > > > > > > > Yes. > > > > Given that I could write either one dump per tape, or with dump (which > > knows what its reading and writing, therefore doesn't really "need" > > filemarks, right?) it would work - no? > > > > How difficult would it be to fix just that part of things, and would it get > > the desired result (usability with dump only)? > > Possibly easy if you just cut for this device only. I mean, it's just > software. But I certainly wouldn't go this route. Well, I added a quirk entry for the OnStream (and support for "rewind immediate" in general) to the SA driver. All that did for me is discover that the Onstream also refuses to respond to an inquiry for block limits (!) I'm going to try a few other things here before giving up on this quest and waiting for someone to get real documentation, but I'm not encouraged by what I'm seeing so far. Given that this thing CLAIMS (in the description that I have) to be an SCSI-II device, the block limit read *has to* be legal. But it fails, which means that I may be looking at some other ugliness. Why do I feel like I'm staring down a black hole on this thing? :-) > > > Yes. Onstream has said that they want to specify more carefully what the > > > soft filemarks will look like. > > > > Grrr... > > No, this is a good thing. This means that if they improve (they'd > *better*!) their h/w so that filemarks etc. are done in h/w there has to > be a compatibility with tapes written with 'soft' marks- so a known format > should be decided on. Well, yes, ok, that makes sense. :-) > > > > > I'm waiting for that information myself. > > > > > > > > Hmmm... that sounds like an indefinite timeframe. > > > > > > No- they've said they'd get that information and unit to me RSN. I believe > > > they're doing the manual this month. I expect to get a unit and a manual > > > by the end of June at the latest. It'll take a couple weeks of work I > > > suspect- there's more than just the rewind, etc..But no promises. > > > > Well that's quite the pickle for me... > > Sorry. > > > > > > > Does anyone have hacks to get even partial functionality? I'm flat-out of > > > > reasonable options with the DATs that I've been using (you know, the old > > > > "data grows" problem) and I've got the fun problem of either finding a > > > > solution to this via the ADR drives or returning it and going with DLT > > > > (about 4x the price). > > > > > > Oddly enough I've found the HP T20 Travan-5 a reasonable price performer- > > > but if you're saying a DDS3 isn't doing it for you, that's not an option. > > > What's the limiting factor? Cost? At 12GB nominal per tape for a DDS-3 > > > you'll need 4-5 to match each Onstream cartridge- so you get a bigger > > > jukebox. > > > > Running dumps to a juke doesn't work if a single filesystem doesn't fit > > on a tape. Unfortunately I am in the position of having a lot of already > > compressed files on big disks and filesystems. > > > > The result is that a single filesystem dump doesn't fit on one tape. > > Therefore, I can't run anything on automatic. This is a serious problem > > from a standpoint of actually getting the dumps done. > > > > 60 days is not a good timeframe for me; I'll live if I have to, and probably > > will keep the drive in that instance, but even partial functionality would > > serve since my needs are only for dump(8) to work. > > Why don't you go to multivolume dumps or use a different backup application? I can do that, but not automatically. I'll live with DAT for now if I have to, but I won't like it. I'm going to continue to play with this a bit more - and that's exactly what it is, since I have no actual documentation on what this drive will and won't handle, and as such I pretty much have to screw around until I find out the hard way :-) -- -- Karl Denninger (karl@denninger.net) Web: fathers.denninger.net I ain't even *authorized* to speak for anyone other than myself, so give up now on trying to associate my words with any particular organization. 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?19990508001936.A597>