Actions
Bug #4496
closedndmpd handles wrongly EOM and EOF conditions
Start date:
2014-01-16
Due date:
% Done:
100%
Estimated time:
Difficulty:
Medium
Tags:
NDMP
Gerrit CR:
External Bug:
Description
Solaris NDMP implementation doesn't conform to NDMP spec in following areas:
- Upon encountering EOF on tape the tape position should remain on BOT (beginning-of-tape) side of the file mark. In our implementation the position remains at EOT (end-of-tape) side of the file mark (as reported by SCSI inquiry).
- If ndmpd attempts to read from a new tape (nothing has been recorded on it) it returns EIO error instead of preferred EOM error.
- Repeated attempts to read at EOM should return EOM error according to the spec. Our implementation returns EOM just the first time and following reads fail with EIO.
While fixing obvious violations of NDMP standard the fix simplifies the code and makes it more reliable:
- ndmpd's magic EOM marker recorded at the end of tape has been purged from code. It was highly unreliable because it was recorded only after encountering EOM and thus couldn't be used for EOT detection for partially full tapes. Moreover it caused problems for some DMA, because they falsely interpreted EOM as a valid file stored on tape.
- current tape record number and block number weren't calculated correctly in some cases
Updated by Jan Kryl over 9 years ago
- Status changed from New to In Progress
- % Done changed from 0 to 100
Updated by Jan Kryl over 9 years ago
- Status changed from In Progress to Pending RTI
Updated by Robert Mustacchi over 9 years ago
Resolved in 9ee94b97c8654689d6a034daec08757fda75d21a.
Updated by Robert Mustacchi over 9 years ago
- Status changed from Pending RTI to Resolved
Actions