Date: 02 Jun 2003 17:27:20 +0200 From: Kern Sibbald <kern@sibbald.com> To: "Justin T. Gibbs" <gibbs@scsiguy.com> Cc: scsi@FreeBSD.org Subject: Re: SCSI tape data loss Message-ID: <1054567640.1578.1912.camel@rufus> In-Reply-To: <3177210000.1054566657@aslan.scsiguy.com> References: <1054490081.1582.1685.camel@rufus> <2846020000.1054498114@aslan.scsiguy.com> <1054503429.1578.1715.camel@rufus> <2897610000.1054507162@aslan.scsiguy.com> <1054544261.1578.1801.camel@rufus> <3177210000.1054566657@aslan.scsiguy.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Thanks for your response. On Mon, 2003-06-02 at 17:10, Justin T. Gibbs wrote: > >> > My personal preference is for data security before performance. > >> > >> There is no potential for lost data if you handle the status that > >> is presented to you. > > > > Could you explain that more in detail? If you mean dig into the > > OS/driver specific details of an MTIOCERRSTAT packet. That *shouldn't* > > be necessary -- at least it is not necessary on Solaris/Linux to > > guarantee data integrity. > > If you properly honor the residual provided in MTIOCERRSTAT, then > you will know what data needs to be rewritten. In otherwords, > all the information required to behave correctly is there. I'll take a look at what the residual provides and see if it corresponds to our data loss. > > >> The tape driver doesn't have any buffering code (unlike Linux which > >> does). The tape drive has a buffer. We are just enabling the use > >> of that buffer. If you really want to do this simply, just do a > >> write filemarks of 0 marks everytime you are about to switch input > >> files. The write marks flushes the device's buffer an guarantees > >> that any residual will be within the fd that you are currently using. > >> This would imply that you only need to explicitly buffer if you support > >> backups from stdin. > > > > I don't mind if the tape drive buffers data as long as it writes > > *all* of that data to the tape and informs me on the next write > > that the LEOM logical EOM in Solaris parlance (or early EOM) > > has been hit. > > FreeBSD does start to fail writes at LEOM, but depending on the tape > type and the amount of buffer, etc. you may or may not get all data > from the buffer to the tape. That is why a residual is provided. Too bad that FreeBSD doesn't start failing writes at LEOM. That would completely remove the need for a residual and hence machine specific programming, and the cost or price for doing so is nothing. > > >> You can never recover the round trip time on the SCSI bus unless > >> you either have a device that allows you to queue more than one > >> command at a time or that buffers. I believe that only FC tape > >> devices support queuing more than one command at a time, but few > >> programs support this anyway (unless you lie and say that a previous > >> write has completed). > > > > I can see that performance concerns you because you wrote the > > driver, > > I care about performance because performance matters. I didn't > write this driver. OK. Yes, performance matters but not when you are losing data. :-)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1054567640.1578.1912.camel>