Date: Sun, 7 Sep 1997 20:13:44 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: joerg_wunsch@uriah.heep.sax.de Cc: hackers@FreeBSD.ORG Subject: Re: Tape question Message-ID: <199709072013.NAA25379@usr07.primenet.com> In-Reply-To: <19970907172200.ZJ25357@uriah.heep.sax.de> from "J Wunsch" at Sep 7, 97 05:22:00 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> Terry, Terry. You ought not to talk about things you neither > understand nor verify before posting. > > Both (mine and his) were the same drivers (st(4)), and all this has > nothing to do with dd(1)'s sync option or such. Raw devices write > just what is being passed down to a write(2) syscall. > > Better talk about things you've got some clue about... The SCSI tape > driver definately doesn't belong to this (and no, you don't need to > change the subject now to match your claims). Well, for one thing, I was under the impression that he was comparing SunOS vs. FreeBSD, with SunOS working and FreeBSD failing, so it wasn't the same driver. Unfortunately, I didn't save the original posting to verify this. I do know that *you* were talking about not having problems with the hardware, but you could easily be using it differently. If you aren't trying to read tapes written on a non-FreeBSD system on a FreeBSD system, that's almost a guarantee *yo* won't have problems. Second, he was complaining about read failures, not write failures. Third, if you'd read the referenced man page instead of immediately flying into another "you don't know what you are talking about" posting, you would see that I was referencing whether or not the driver permitted partial blocks to be written, or if it wrote full blocks when you requested partial blocks (effectively, osync), and whether it expected partial blocks on reads, or expected only full block output had taken place (a stupid assumption, but one shared by most NCR tape drivers, which is why you must write tapes from other systems -- like Sun machines, which support partial block writes -- through dd using conv=osync). Fourth, a raw device can be written to pad requests to media block boundries, despite it appearing to be a character at a time device. TK50's are well know helical scan tape devices that require that kind of software coddling. Finally, if he were to pipe through dd and use conv=osync, he would probably not have the problems he's having... but that was not the intent of my posting, since he has legacy tape issues which that would not address. In any case, that hardware is capable of partial block reads and writes, so it's clearly a driver problem if they aren't working under one OS, but are under another. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199709072013.NAA25379>