[AFS3-std] [RPC Request] 64-bit volume IDs, quotas, and block usages

[Andrew Deason]

Per suggestions from Jeffrey Altman and others, here are what I believe
to be the requirements for 64-bit fields pertaining to volume IDs,
volume quotas, and block usage on volumes/partitions.

The format resembles what Jeffrey posted as an example earlier, but I
separated the affected RPCs according to what underlying struct changed
in the RPC (if any); I just found it easier to follow. This is what's in
the parentheses by "Affected RPCs". Some RPCs are listed more than once
because of this: once for each structure changed. I also merged some
fields into the same section when the list of affected RPCs was
identical.

Anyway, here's what I have:

   1. Package RXAFS
      1. 64-bit unsigned values for Volume IDs
            1. Affected RPCs: GetVolumeStatus, SetVolumeStatus

            2. Affected RPCs (AFSFid): FetchData, FetchACL, FetchStatus,
            StoreData, StoreACL, StoreStatus, RemoveFile, CreateFile,
            Rename, Symlink, Link, MakeDir, RemoveDir, GiveUpCallBacks,
            BulkStatus, SetLock, ExtendLock, ReleaseLock, Lookup,
            DFSSymlink
            
            3. Affected RPCs (FsCmdInputs): FsCmd

            4. Affected RPCs (AFSVolumeInfo): GetVolumeInfo

            5. Affected RPCs (AFSFetchVolumeStatus): GetVolumeStatus

      2. 64-bit unsigned values for volume quotas
            1. Affected RPCs (AFSFetchVolumeStatus): GetVolumeStatus
            
            2. Affected RPCs (AFSStoreVolumeStatus): SetVolumeStatus

      3. 64-bit unsigned values for volume blocks in use, partition
      blocks in use, and maximum partition blocks
            1. Affected RPCs (AFSFetchVolumeStatus): GetVolumeStatus

   2. Package RXAFSCB
      1. 64-bit unsigned values for Volume IDs
            1. Affected RPCs (AFSFid): CallBack

            2. Affected RPCs (AFSDBCacheEntry): GetCE

   3. Package VL
      1. 64-bit unsigned values for Volume IDs
            1. Affected RPCs: DeleteEntry, GetEntryByID, GetNewVolumeId,
            ReplaceEntry, UpdateEntry, SetLock, ReleaseLock

            2. Affected RPCs (vldbentry): GetEntryByName, CreateEntry,
            GetEntryByID, ReplaceEntry ListEntry, ListAttributes,
            LinkedList

            3. Affected RPCs (VldbUpdateEntry): UpdateEntry,
            UpdateEntryByName

            4. Affected RPCs (VldbListByAttributes): ListAttributes,
            LinkedList

            5. Affected RPCs (vital_vlheader): GetStats

   4. Package AFSVol
      1. 64-bit unsigned values for Volume IDs
            1. Affected RPCs: CreateVolume, Clone, TransCreate,
            GetNthVolume, SignalRestore, SetIdsTypes, ReClone,
            ListOneVolume, NukeVolume, XListOneVolume,
            ConvertROtoRWvolume, SplitVolume

            2. Affected RPCs (restoreCookie): Restore, Forward,
            ForwardMultiple

            3. Affected RPCs (volser_status): GetStatus

            4. Affected RPCs (volintInfo): ListVolumes, ListOneVolume,
            SetInfo

            5. Affected RPCs (transDebugInfo): Monitor

            6. Affected RPCs (volintXInfo): XListVolumes, XListOneVolume

      2. 64-bit unsigned values for volume quotas, and number of volume
      blocks in use
            1. Affected RPCs (volintInfo): ListVolumes, ListOneVolume,
            SetInfo

            2. Affected RPCs (volintXInfo): XListVolumes, XListOneVolume

   5. Package TC
      1. 64-bit unsigned values for Volume IDs
            1. Affected RPCs (tc_dumpDesc): PerformDump

            2. Affected RPCs (tc_restoreDesc): PerformRestore


Is this specific enough, or do we want individual fields outlined for
volumes? (e.g. "64-bit unsigned value for parent volume ID", "64-bit
unsigned value for clone volume ID", ...) And would it be desirable to
up the other FID fields to 64 bits, as well? Since we're already
altering everything needing an FID if we change the volume ID size.

Feel free to point out any problems. I figure field size changes like
this are less controversial in and of themselves, so they'd make for a
good first example.

-- 
Andrew Deason
adeason@sinenomine.net