Project

General

Profile

Actions

Bug #4496

closed

ndmpd handles wrongly EOM and EOF conditions

Added by Jan Kryl over 9 years ago. Updated over 9 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
cmd - userland programs
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
Actions #1

Updated by Jan Kryl over 9 years ago

  • Status changed from New to In Progress
  • % Done changed from 0 to 100
Actions #2

Updated by Jan Kryl over 9 years ago

  • Status changed from In Progress to Pending RTI
Actions #3

Updated by Robert Mustacchi over 9 years ago

Resolved in 9ee94b97c8654689d6a034daec08757fda75d21a.

Actions #4

Updated by Robert Mustacchi over 9 years ago

  • Status changed from Pending RTI to Resolved
Actions

Also available in: Atom PDF