Date: Thu, 1 Feb 2001 18:33:11 +0100 (CET) From: Soren Schmidt <sos@freebsd.dk> To: mike@sentex.net (Mike Tancsa) Cc: stable@freebsd.org, sos@freebsd.org Subject: Re: ast0: TAPE <OnStream DI-30> Message-ID: <200102011733.SAA66640@freebsd.dk> In-Reply-To: <4.2.2.20010201104340.013e00d8@marble.sentex.net> from Mike Tancsa at "Feb 1, 2001 10:57:18 am"
next in thread | previous in thread | raw e-mail | index | archive | help
It seems Mike Tancsa wrote: > > I have been trying out the OnStream DI-30 in STABLE which come up as > ast0: TAPE <OnStream DI-30> at ata1-master using WDMA2 > > Dump seems to work with it OK in that I can dump a file system and restore > it OK. But tar does not. I have tried plan old tar and tar with block size > specifications, but no dice. > > ruby2# tar -b 4096 -c -f /dev/nrast0 altq-3.0 > tar: can't write to /dev/nrast0 : Input/output error > > It just gives a series of > ast0: bad request, must be multiple of 32768 > ast0: bad request, must be multiple of 32768 > ast0: bad request, must be multiple of 32768 > ast0: bad request, must be multiple of 32768 > ast0: bad request, must be multiple of 32768 > ast0: bad request, must be multiple of 32768 > > no matter what block size I try. You havn't what it says to you ie 32k blocksize ie: tar cvbf 64 /dev/rast0 bla bla.... > The other quirk I noticed is that after a dump, > ast0: WEOF - ILLEGAL REQUEST asc=24 ascq=00 error=04 Well, the Onstream has no notion of filemarks, at least not the way we support it. > Is this just a limitation of the hardware and driver ? It looks like they > have LINUX support on their web page. Too bad they are not doing the same > for FreeBSD. I have a drive here that onstream sent me back when with docs, but to be brutally honest the drive and especially the firmaware sucks.. The drive has no idea how to handle bad spots on the media, the driver has to read back up to 1 Mbyte worth of buffer when the drive hits a write error, then wind forward some inches, and retry the write again with the queued up and from the OS's Point of view already written data, then if that still fails... you get the point... Another thing is that for this to work, the drive has to be set into a 32.5Kb block mode where the 32K carry userdata, and the 512bytes carry block info, like blocknumber etc, since you have to have that info when reading, since you must keep track of which blocks you have read, since they might be repeated later due to bad spots and the above hit'n'write strategy left one double block around... So, since I have not found a way to deal with this in a satisfactory way (malloc'ing 1 Mbyte worth of buffer in the kernel is not fun), the support we have can't handle tapes with bad spots on it... I wouldn't trust my data to such a poorly implemented device... However the drive sits in one of my dev machines, and I hack on the driver from time to time, so it will probably be supported at some point in the future... -Søren To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200102011733.SAA66640>