[stgt] Bug report stgt vtl

[Mark Harvey]

On Wed, Apr 8, 2009 at 7:51 PM, Albert Pauw <albert.pauw at gmail.com> wrote:
> I may have found a glitch in the vtl code.
>
> Here's what I had:
>
> vtl configured with 8 tapes and 3 drives.
>
> I loaded a tape in the first drive
>
> mtx -f /dev/sg6 load 1 0
>
> Checked the status
>
> mtx -f /dev/sg6 status
>
> which showed the tape in the drive.
> Now I write two tar images to it:
>
> tar cvzf /dev/nst0 /etc/bacula
> tar cvzf /dev/nst0 /etc/iscsi
>
> (just example backups, not to big)
>
> I rewind the tape
>
> mt -f /dev/nst0 rewind
>
> And am able to read them both back:
>
> tar tvzf /dev/nst0
> mt -f /dev/nst0 fsf
> tar tvzf /dev/nst0
>
> Now I unload the tape:
>
> mtx -f /dev/sg6 unload 1 0
OK, this should have fail.. In the real world, you can't eject a tape
when it is NOT at BOT..


>
> All working fine, now I load the tape in another tape drive (or the same
> one, it doesn't matter):
>
> mtx -f /dev/sg6 load 1 1
>
> When I try to read the tar images immediately I get an error, however when I
> rewind the tape first it works fine,
> both images are there.
>
> The point I want to make is that there are differences in tape behaviour on
> rewinding before eject.
> As I configured the tapes as LTO type it should rewind before eject. A load
> would always start
> at the beginning. A DLT tape, through its very design, would stay at its
> position. As the code is
> at the moment, it always behave as the latter, its current position is at
> the last state before eject.

The media file should have been closed at time of ejecting.

>
> It would be nice to have the option of changing this behaviour.
>
> Albert
>
Many thanks for the bug reports.

Mark
--
To unsubscribe from this list: send the line "unsubscribe stgt" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html