Kernel 4.19.5 breaks writing to tape
 

Greetings.

I'm having trouble with kernel version 4.19.5 in Slackware64-current where I am not able to write data to my LTO tape drives. Using a Dell PowerVault 132t, I can run the mtx command to load/unload and move tapes around fine, and the mt command also works fine with accessing tapes in either of the LTO2 drives. However, if I run the command "tar -cvf /dev/st0 /path/to/backup", the system acts like it is writing the files to tape, but nothing seems to get actually written. Running a "tar -tvf /dev/st0" immediately exits. After hours of troubleshooting, rolling back to kernel-generic-4.19.4 and everything works fine again. This same thing is happening on a second Slackware64-current machine, with a different SCSI card, accessing a second PowerVault 132t. There are no logs generated in /var/log/syslog or /var/log/messages either. Tried kernel 4.19.6 and it does the same thing as 4.19.5. Looked at the 4.19.5 changelog, and I can't see anything obvious which would be responsible for causing this behavior.

Just wondering if anyone else can confirm this happening on their systems?

Good morning. Slackware64-current is now at kernel 4.19.7.

Does the issue happen with the newer kernel?

Thanks for the reply. Didn't realize that 4.19.7 was out yet. I will give it a try.

Unfortunately, 4.19.7 behaves the same as 4.19.5 and 4.19.6. I noticed I can read a tape that was dumped with tar in 4.19.4, but as soon as I try to tar something new in 4.19.7, I am unable to read it back.

Possibly connected to this issue: https://www.linuxquestions.org/quest...on-4175643737/

But also possibly not... Just a thought.

That was also my first thought rkelsen. But that bug existed on all 4.19.y versions and I think was most prevalent on nvme drives or devices where mq was used heavily. Not sure about tape. *edit* although high volumes of data copy were very much a part of the scenario where the corruption hit
Supposedly 4.19.8 will be released this weekend and that bug will be fixed.
Couldn't hurt to wait and test again after 4.19.8 is released...
If it still doesn't work you may want to report it to kernel devs....

I saw that, but am not sure this is the issue in my case, since it isn't really corruption that is happening but actually nothing at all being written to the tape except for filemarks. It is like the data is being sent over the SCSI bus, but the drive is not accepting it. Plus, up until 4.19.5, everything worked fine. Copying files from disk to disk appears to be fine as well.

Will do. Not a critical problem because I can keep 4.19.4 on my main server, and test newer kernels on the second machine.

Unfortunately, still broken with 4.19.8.

Reported to kernel Bugzilla... bug #201935.

https://bugzilla.kernel.org/show_bug.cgi?id=201935

Update: the bug has been found and corrected. Per the Bugzilla report:

Looks like it will be included with 4.19.11, which is scheduled to be released this Thursday afternoon, UTC.

Edit in: The 4.19.11 update has been released and does include this patch.

Ha.. I'll be...
Good job Barcoboy :D

Thanks tramtrist!

I just installed 4.19.11 on one of my machines, and my tape backups are working again. :)

Thanks everyone.