Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 26 Jan 2014 15:46:06 -0700
From:      "Justin T. Gibbs" <gibbs@scsiguy.com>
To:        Ben Laurie <ben@links.org>
Cc:        freebsd-scsi@freebsd.org
Subject:   Re: Dropped interrupts
Message-ID:  <888F991A-96C7-48C0-AAC6-0D432BD78A46@scsiguy.com>
In-Reply-To: <CAG5KPzwvBoBvh210Vn5GG6eBVNXKWCkuh6J_FLGao0L6aPAmcw@mail.gmail.com>
References:  <CAG5KPzxUAnORPSyJDrSdBBNE7MBi-dD=M6=E1rMG%2Bc8rn4deUQ@mail.gmail.com> <AE41EB93-26BD-4BD0-9913-7CD0A5B6E1A4@scsiguy.com> <CAG5KPzwR5=WNKc5hck8F7CtCtk3mivwYFRFeCJT_zWdnetW=3w@mail.gmail.com> <84D23688-DDC6-421E-9D21-3DA646229038@scsiguy.com> <CAG5KPzxqxmzfnAiUyVyApMs5XqKpH0F0sbTxy1h=4cL=rEROpQ@mail.gmail.com> <CAG5KPzyPXLEOAFKTAW%2BJaai=XbT3mi5yGHs1LnUbMcD-LfQ1YQ@mail.gmail.com> <CAG5KPzzVpvH=miguqKnO0pA2jmWm-_7s7W-Nbh%2BVeHKv7x7ikw@mail.gmail.com> <8680A21D-78D7-4B65-A502-17F0C3B70291@scsiguy.com> <CAG5KPzwvBoBvh210Vn5GG6eBVNXKWCkuh6J_FLGao0L6aPAmcw@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Jan 26, 2014, at 1:52 AM, Ben Laurie <ben@links.org> wrote:

> On 25 January 2014 17:15, Justin T. Gibbs <gibbs@scsiguy.com> wrote:
>> On Jan 24, 2014, at 10:44 PM, Ben Laurie <ben@links.org> wrote:
>>=20
>>> Aha, finally got the error again=85
>>=20
>> I don=92t know enough about your backup or Bacula to know if this is =
amount that should be written, but we attempted a write in variable =
block mode of 64512 bytes.
>=20
> I don;t think there's anything wrong with that. Not at the machine
> right now, but I think that's actually the default max block. No idea
> why.
>=20
>> The command, data transfer list, and controller state are all =
consistent with this.  The command was successfully transferred to the =
tape drive, but it never transitioned to data phase to allow us to begin =
the data transfer.  (In parallel SCSI, the target controls all state =
transitions).
>>=20
>> Since there are no parity errors or other indications of a transport =
error, my hunch is that this is a tape drive issue.  Are you running the =
latest available firmware for it?
>=20
> No idea, its a very old LTO-2 drive. I'll see if I can find an update.
>=20
>> How many write cycles do you have on your media?
>=20
> I have seen this error on brand new media. I'd guess the most cycles
> any tape has had is around 10.
>=20
>> When was the last time you cleaned the drive?
>=20
> LTO drives are self-cleaning. So ... never.

This is a popular misconception.  LTO drives include brushes deployed =
during load or unload to remove large particle contamination off the =
head.  This increases the time interval between traditional cleanings, =
but doesn=92t make them unnecessary.  Certain LTO drives will tell you =
(e.g. light a LED) when they require cleaning, but I don=92t know if =
this is one of them.  There have also been firmware bugs on some drives =
that prevent the cleaning indicator from working as expected.

If the drive has over 500 hours on it, I would suggest a cleaning pass.

=97
Justin=



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?888F991A-96C7-48C0-AAC6-0D432BD78A46>