From owner-freebsd-scsi Fri May 7 9:17:32 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 0CA4F150C8 for ; Fri, 7 May 1999 09:17:28 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from feral.com (mjacob@feral.com [192.67.166.1]) by feral.com (8.8.7/8.8.7) with ESMTP id JAA00745; Fri, 7 May 1999 09:17:22 -0700 Date: Fri, 7 May 1999 09:17:22 -0700 (PWT) From: Matthew Jacob Reply-To: mjacob@feral.com To: Karl Denninger Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: Question - Onstream SCSI Streamer In-Reply-To: <19990507110558.A614@Denninger.Net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > > > 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. > > > > Software filemarks (the drive doesn't know how to write them?!) could be a > > > bigger problem. > > > > 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. > > > > > > I'm willing to take a look at this (since I have one) provided I can wrangle > > > > > enough information to actually do so. > > > > > > > > > > > > > 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? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message