On Wed, Aug 28, 2002 at 03:31:50PM -0500, Amy Tanner wrote: > On Wed, Aug 28, 2002 at 01:13:32PM -0700, Jay Lessert ([EMAIL PROTECTED]) wrote: > > On Wed, Aug 28, 2002 at 02:13:03PM -0500, Amy Tanner wrote: > > > > > > > > We recently switched to hardware compression because we > > > > > got a new tape changer. Perhaps that's the cause of the > > > > > problems. > > > > Sounds unlikely. You don't get data timeout from a tape drive. > > What I meant was that because we switched to a new tape changer, we > decided to turn on hardware compression and turn off software > compression. Perhaps the change of compression choices is the source of > the problems.
And what *I* meant :-) is that if you are dumping to holdingdisk, it is not possible for *anything* you do with the tape drive to cause data timeout, even if you hang the tape drive from the ceiling and use it for a pinata! You would get some kind of taper failure, but not a data timeout. > Yes, we're running dump on linux ext2. However, the kernel and dump > versions have not changed from when they were working until now (not > working). The kernel/dump issues in question are data and activity-dependent, not hard failures. Just because it worked yesterday doesn't mean it will work (as well) today, unless your data and usage patterns are static. > Also, note: some file systems on these 2 machines DO dump successfully, > and some don't. So it's data dependent, which is not surprising. > And it's not always the same ones that fail or succeed. > I can't find a pattern. *That* is a little surprising. Though if it is the case that you have zero file systems that *always* fail (e.g., 50% of the dumps on any single file system succeed in a given week), maybe you can just leave it alone and let the other admin fix it when they get back. :-) -- Jay Lessert [EMAIL PROTECTED] Accelerant Networks Inc. (voice)1.503.439.3461 Beaverton OR, USA (fax)1.503.466.9472