On Wed, Apr 8, 2009 at 7:51 PM, Albert Pauw <albert.pauw@xxxxxxxxx> 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
