Date: Wed, 28 Aug 2002 09:58:18 -0700 (PDT) From: Matthew Jacob <mjacob@feral.com> To: Eric Lee Green <eric@badtux.org> Cc: Cejka Rudolf <cejkar@fit.vutbr.cz>, freebsd-stable@freebsd.org Subject: Re: EOT tape handling changed? Message-ID: <Pine.BSF.4.21.0208280955050.5368-100000@beppo> In-Reply-To: <200208280942.41370@badtux.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 28 Aug 2002, Eric Lee Green wrote: > On Wednesday 28 August 2002 09:20 am, Matthew Jacob wrote: > > We can argue until the cows come home about whether this is correct or > > not. We won't. I *do* agree that breaking 3rd party backup packages is a > > problem. Let me do some thinking about how to address this. > > How about returning an error upon the *NEXT* write? Or do you already do > that? (My FreeBSD machine with a tape drive is still packed up from my move, > so I can't test it, sigh). I *can* and *do* do this (for example, for fixed block mode), but my experience with the Solaris driver led me to the conclusion that maintaining virtual state is very hard to get bug free. You don't want to do this if at all possible. > Regarding tape spanning, when I was involved with the BRU folks we already > had provisions for detecting (and discarding) duplicated data upon tape > spanning, because that was necessary to work upon most commercial Unixes. I > would assume that all commercial tape backup programs and most open source > programs have similar provisions, in order to deal with Unix variants that > have the issue of the final write on a tape not necessarily making it onto > the tape. In other words, it's nice that you solved this problem, but it > isn't really solving anything for most backup programs, because they must > already do a work-around for non-BSD Unix OS's where the final write may or > may not have made it to tape. The problem here is that N applications have N methods to detect and work around M different OS behaviours. The most you can ever do is never change things. But then it makes simple and naive applications blow up. 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. But I assure you, 5.0 *will* have this behaviour. -matt 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?Pine.BSF.4.21.0208280955050.5368-100000>