SD Data Structures
Keywords: developers

#
SD Data Structures

In the Storage daemon, there is a Device resource (i.e. from conf file) that describes each physical device. When the physical device is used it is controled by the DEVICE structure (defined in dev.h), and typically refered to as dev in the C++ code. Anyone writing or reading a physical device must ultimately get a lock on the DEVICE structure - this controls the device. However, multiple Jobs (defined by a JCR structure src/jcr.h) can be writing a physical DEVICE at the same time (of course they are sequenced by locking the DEVICE structure). There are a lot of job dependent "device" variables that may be different for each Job such as spooling (one job may spool and another may not, and when a job is spooling, it must have an i/o packet open, each job has its own record and block structures, ...), so there is a device control record or DCR that is the primary way of interfacing to the physical device. The DCR contains all the job specific data as well as a pointer to the Device resource (DEVRES structure) and the physical DEVICE structure.

Now if a job is writing to two devices (it could be writing two separate streams to the same device), it must have two DCRs. Today, the code only permits one. This won't be hard to change, but it is new code.

Today three jobs (threads), two physical devices each job writes to only one device:

      Job1 -> DCR1 -> DEVICE1
      Job2 -> DCR2 -> DEVICE1
      Job3 -> DCR3 -> DEVICE2

To be implemented three jobs, three physical devices, but job1 is writing simultaneously to three devices:

      Job1 -> DCR1 -> DEVICE1
              -> DCR4 -> DEVICE2
              -> DCR5 -> DEVICE3
      Job2 -> DCR2 -> DEVICE1
      Job3 -> DCR3 -> DEVICE2

      Job = job control record
      DCR = Job contorl data for a specific device
      DEVICE = Device only control data