From owner-freebsd-hackers Tue Sep 2 14:19:24 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA28278 for hackers-outgoing; Tue, 2 Sep 1997 14:19:24 -0700 (PDT) Received: from sag.space.lockheed.com (sag.space.lockheed.com [192.68.162.134]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id OAA28268 for ; Tue, 2 Sep 1997 14:19:19 -0700 (PDT) Received: from localhost by sag.space.lockheed.com; (5.65v3.2/1.1.8.2/21Nov95-0423PM) id AA13948; Tue, 2 Sep 1997 14:19:30 -0700 Date: Tue, 2 Sep 1997 14:19:30 -0700 (PDT) From: "Brian N. Handy" To: hackers@freebsd.org Subject: Tape question Message-Id: X-Files: The truth is out there Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Heya folks, I've got a guy here who's got a pile of data on exabyte tapes, and he's written a C program to read the stuff off the tapes and do [mumble I don't know] with it. What follows is his brief description of the problem. If anyone has any comments or suggestions I'd like to hear them. I can come up with some sample code if this isn't sufficient. Thanks, Brian ---------- Forwarded message ---------- The problem is easily described: - The Exabyte tapes to be read have a variable (logical) block size, it typically is 8192 bytes, but often shorter. - My original c program always attempted to read a 8192 byte block: nn = read(unit,buffer,8192); - On the sun this worked, it would read one (logical) block, and return the actual number of bytes read. - In FreeBSD this created unpredictable results, if the logical block was shorter than 8192. I don't know how much it actually read, but there certainly was a discrepancy between the number of bytes read, and the number returned. Also, running the program twice on the same data created different results. - In my particular case a fix was possible, since the actual logical block size can be predicted by an algorithm: nn = read(unit,buffer,predicted_block_size); But such a thing shouldn't be necessary. It defeats the idea of a variable block size format.