Design notes on MDS intreaction with DS_REPORTAVAIL

A data server (DS) communicates the availability of a data set to the metadata server (MDS) via the DS_REPORTAVAIL call in the Control Protocol.

The life of a data set drives the sending of DS_REPORTAVAIL to the mds:

data set is created
- Message indicates creation
- No matching record found in the MDS
  - What if one is found?
data set is offlined for maintenance
- Message indicates temporary unavailability
- No matching record found in the MDS
  - mds must have rebooted, right?
- Matching record found
  - Record information
data set is deleted
- Message indicates deletion
- No matching record found in the MDS
  - mds must have rebooted, right?
  - What happens if a client subsequently accesses a file on that data set?
- Matching record found
- Record information

Besides the life cycle, we also have to examine what happens at the DS and MDS:

DS reboots
- Message indicates reboot
- No matching record in the mds
  - mds must have rebooted, right?
  - Add record
- Matching record in the mds
  - Is there anything we want to record?
    - Time of last DS_REPORTAVAIL?
    - What about state information about the data set?
- What should the MDS do if it first gets a DS_SHUTDOWN?
MDS reboots
- DS eventually gets a DSERR_STALE_DSID (or another error code) from the MDS in response to a call
- Needs to send a DS_REPORTAVAIL for each data set
DS is powered down, data set is removed
- Disks are gone, how do we detect this at boot?
- Went to single user mode, no network
  - How do we detect this once the DS goes live?

Labels