Folks,
I don't perform a tape backup nor update this machine very often so it has taken a while for me to spot this. I backup to tape which takes a few tapes to complete, in the past this has worked fine, when one tape is full dump recognises this and prompts for a new tape. I attempted a backup a couple of days ago and now dump says "write error" and then asks if it should restart the dump, answering yes does restart the dump from the beginning, answering no causes dump to exit. As I said, this machine does not get updated often so I suspect this problem has been there for a while. The kernel was built with v1.240 of st.c, this version causes dump to misbehave. I reverted st.c back to v1.231 (this was the version of st.c that was used in the kernel that made the last successful backup). After adding a couple of FALLTHROUGH comments to get v1.231 to compile I booted to this kernel and found that dump behaved correctly again. Given the above it looks like a change to st.c between v1.231 and v1.240 has broken multi-tape dumps. Fortunately most of the commits in that bracket are cosmetic, one that does stand out is v1.238 which does modify the tape position handling. I will try a kernel that incorporates v1.237 of st.c and see what happens. Unfortunately, testing is a very slow process as it takes about 3 hours to fill a tape though I may be able to reduce that by using a lto-1 tape instead which should halve the time taken to fill a tape. -- Brett Lymn -- Sent from my NetBSD device. "We are were wolves", "You mean werewolves?", "No we were wolves, now we are something else entirely", "Oh"
