Date: Wed, 16 Jun 2010 16:31:50 -0700 From: Matthew Jacob <mj@feral.com> To: freebsd-scsi@freebsd.org Subject: Re: sa: write returns 0 = LEOM? Message-ID: <4C195EE6.1050207@feral.com> In-Reply-To: <AANLkTikULvhu5TRVDNAY59UvKII-BuBYBvDe83jQFLXR@mail.gmail.com> References: <AANLkTikULvhu5TRVDNAY59UvKII-BuBYBvDe83jQFLXR@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 6/16/2010 3:52 PM, Dustin J. Mitchell wrote: > I'm investigating a user bug report in Amanda: > http://forums.zmanda.com/showthread.php?t=2832 > > The problem boils down to a write(2) call for a SCSI tape device > (/dev/nsa0) returning 0 after quite a bit of data and a number of > filemarks have been written. Jean-Louis suspected that this was an > early warning EOM indication, and that a subsequent write() would > succeed, with Amanda having been duly warned that a physical EOM is > coming up. That is, I believe, a specific feature of Solaris (EOM detection triggers a zero write, but allows for trailer records). I seem to recall helping architect this back in 1996. > But looking at scsi_sa.c, this doesn't seem to be the > case. It looks like an early warning would result in a successful > write instead, because resid is set to zero. > > cam/scsi/scsi_sa.c: > 2418 /* > 2419 * Handle filemark, end of tape, mismatched record sizes.... > 2420 * From this point out, we're only handling read/write cases. > 2421 * Handle writes&& reads differently. > 2422 */ > 2423 > 2424 if (csio->cdb_io.cdb_bytes[0] == SA_WRITE) { > 2425 if (sense_key == SSD_KEY_VOLUME_OVERFLOW) { > 2426 csio->resid = resid; > 2427 error = ENOSPC; > 2428 } else if (sense->flags& SSD_EOM) { > 2429 softc->flags |= SA_FLAG_EOM_PENDING; > 2430 /* > 2431 * Grotesque as it seems, the few times > 2432 * I've actually seen a non-zero resid, > 2433 * the tape drive actually lied and had > 2434 * written all the data!. > 2435 */ > 2436 csio->resid = 0; > 2437 } > > Yes, I remember this code. I remember on doing test readbacks that the residual reported was in fact incorrect- the data had actually been written. But this was really a long while back (at least 8 years ago). > That said, I don't know my way around the kernel source, so I'm > probably missing something obvious. So: > > 1. What could cause a write syscall to return 0? > I'll try and look into this. Do you happen to know whether the device you experienced this on was set in fixed block or variable block mode? > 2. Since we will be using early warning in the next version of Amanda, > hints as to the best way to handle early warning from userspace would > be appreciated. > > Urrr.... I used to have opinions about this. Now I'm not so sure. Expecting consistent behaviour from platform to platform is tough. Can't you write until you get a hard failure, back up one record (which, of course, you've hung onto), write a trailer label and then ask for a new tape?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4C195EE6.1050207>