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 (jayl AT accelerant DOT
> net) 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 jay_lessert AT accelerant DOT net
Accelerant Networks Inc. (voice)1.503.439.3461
Beaverton OR, USA (fax)1.503.466.9472
|
