Date: Sat, 25 Apr 1998 18:07:39 -0400 From: "Louis A. Mamakos" <louie@TransSys.COM> To: Harlan Stenn <Harlan.Stenn@pfcs.com> Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: does CAM do this? Message-ID: <199804252207.SAA00632@whizzo.TransSys.COM> In-Reply-To: Your message of "Sat, 25 Apr 1998 16:37:50 EDT." <23743.893536670@brown.pfcs.com> References: <23743.893536670@brown.pfcs.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > Perhaps I've come in the middle here, but typically you simply issue
> > a read(2) system call with as large a block size as you're willing or
> > able to accomodate. The byte count returned is the size of the tape
> > block which was actually read. This sort of scheme works even if every
> > block within a tape file is a different block size.
>
> That works for reading a tape, but not for copying or writing tapes.
>
> Sometimes, the tape *must* be written with particular blocksizes for
> bootloaders or foreign systems.
>
Clearly, you only write a block the same size as you read it:
int len;
char buffer[MAX_BLOCKSIZE_YOU_EXPECT_OR_OS_OR_HARDWARE_CAN_USE];
do {
len = read(goes_in_a, buffer, sizeof(buffer));
if (len < 0) {
perror("input error");
exit(-1);
}
if (len == 0) {
/* eof */
break;
}
if (write(goes_out_a, buffer, len) != len) {
perror("output error");
exit(-1);
}
} while (len);
If the whole tape handling model has changed significantly from how the
computing world has been dealing with them for 20 years, then there may
be something else terribly wrong. The SLI big existing in mainframe
channel programs long before there was an 8086, and was just just for
this reason.
louie
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?199804252207.SAA00632>