Date: Thu, 29 Aug 2002 12:00:33 +0200 From: Cejka Rudolf <cejkar@fit.vutbr.cz> To: Matthew Jacob <mjacob@feral.com> Cc: stable@FreeBSD.ORG Subject: Re: EOT tape handling changed? Message-ID: <20020829100033.GA2174@fit.vutbr.cz>
next in thread | raw e-mail | index | archive | help
Matthew Jacob wrote (2002/08/28):
> I *can* and *do* do this (for example, for fixed block mode), but my
Are you sure? Here is my small test program:
-- copy.c:
#include <sys/types.h>
#include <sys/uio.h>
#include <errno.h>
#include <stdio.h>
#include <unistd.h>
#define BUFSIZE (32768*8)
int main(void)
{
char buf[BUFSIZE];
int cnt;
errno = 0;
while (1) {
cnt = read(STDIN_FILENO, buf, BUFSIZE);
if (cnt != BUFSIZE)
fprintf(stderr, "read(): Just small warning...\n");
cnt = write(STDOUT_FILENO, buf, BUFSIZE);
fprintf(stderr, "write(): %d (%d)\n", cnt, errno);
if (cnt != BUFSIZE)
sleep(1);
}
return 0;
}
--
And here are my results (./copy < big_dev_urandom_file.dat > /dev/nrsa0
starting some space before the end of tape):
--
...
write(): 262144 (0)
write(): 262144 (0)
write(): 262144 (0)
write(): 0 (0)
write(): 65536 (0)
write(): 65536 (0)
write(): 65536 (0)
...
--
or
--
...
write(): 262144 (0)
write(): 262144 (0)
write(): 262144 (0)
write(): 196608 (0)
write(): 65536 (0)
write(): 65536 (0)
write(): 65536 (0)
...
--
or with just 32768 long buffer:
--
...
write(): 32768 (0)
write(): 32768 (0)
write(): 32768 (0)
write(): 0 (0)
write(): 32768 (0)
write(): 0 (0)
write(): 32768 (0)
write(): 0 (0)
write(): 32768 (0)
...
--
Do you have another results?
> I'm not sure that this is right. The NetBSD driver will do the same
> behaviour at this point.
Maybe it has been changed too? Or maybe afbackup on NetBSD has problems
(however there is a trivial and universal fix for both cases, no problem)
as in FreeBSD now, even if sources of afbackup take NetBSD into account.
Can anybody try EOT handling in NetBSD in the reality? I'm sorry, I'm
afraid that I could not do this.
> The problem is that you cannot return a residual if you return an error.
> For tape drives that then write *partial* final records (e.g., if you
> have EEW off), you cannot know exactly what you wrote. Therefore, when
Please, what is "EEW off"?
> you read things back, you end up with duplicated data when you do tape
> spanning.
I'm not sure, if I see this problem too. If I understand correctly,
previous behaviour was that when write() was successful just partially,
it returned -1/ENOSPC, so some data could be duplicated on the next
tape. Now write() should return partial count, then zero and
then -1/ENOSPC...
> I think in my desire to fix -stable for somebody I went too far and
> broke things. I'll figure out a reasonable compromise toot suite because
> 4.7 is closing on 1 September.
... And what about write() returning partial count and then -1/ENOSPC?
Without returning zero as an interstep. Your problem disappear and
existing applications should be happy and this is the way write()
on the disk works (I hope :-).
> But I assure you, 5.0 *will* have this behaviour.
I'm pacified with this :-) It looks good, but please - if it is
not documented somewhere, please document it on some manual page
(e. g. write(2)). I think that this is an important semantic change.
PS: I have/had another problem with timeouts - what do you think about
increasing the standard value for SA_IO_TIMEOUT? In case of M2 from
Exabyte, there is SmartClean feature, that when there are too much
write errors during write operation, it rewinds tape at the beginning
(up to 3 minutes), where is some cleaning tape and tries to clean heads
(I hope no more that 2 minutes), returns to the previous position (again
up to 3 minutes) and finishes write - so I'm trying to increase
SA_IO_TIMEOUT from 4 to atleast 8 minutes (but I'm rather trying 15 now,
because I realized this possible source of timeouts very recently, so
I'm just experimenting... ;-).
Have a nice day ;-)
--
Rudolf Cejka <cejkar at fit.vutbr.cz> http://www.fit.vutbr.cz/~cejkar
Brno University of Technology, Faculty of Information Technology
Bozetechova 2, 612 66 Brno, Czech Republic
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?20020829100033.GA2174>