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

[Jeffrey Altman]

I believe the format is sufficient to describe the impact of the change.
However, I believe that what is insufficiently described here is how the
proposal to increase the volumeId number from a 32-bit to a 64-bit
value will be done in such a way as to permit backward compatibility
with existing clients and servers.   A server that has a volumeId greater
than the 32-bit volumeId space is automatically going to be unable to
share the affected volume group with an existing client.  Nor could an
existing file server be used in a mixed environment with any server that
supports this larger volumeId.

As such I believe any proposal to increase the size of the volumeId
must be combined with a rationale for why the volumeId name space must
be increased by growing the size of the volumeId.  From my perspective
the volumeId space is sufficiently large.  The problem is not how many
volumeIds there are but how they are used.  Unique volumeIds are allocated
for the normal (rw) volume, the .readonly and the .backup.  Those are
the ones that are exposed to the clients as part of a volume group. 

The rest of the volumeIds that are assigned are used for what I will
categorize as maintenance or backup purposes.  In particular, they are
used for snapshots which could be much better represented as the normal
(rw) volumeId augmented by a 64-bit timestamp that has granularity finer
than 1ms.  Assigning a new volumeId results in the problem that the
volume group size must grow indefinitely to be able to support an
arbitrary number of snapshots.  If we want to support arbitrary client
accessible views of a volume at any point in time, the client should
not need to figure out which of the thousands of random volumeIds is
the readonly snapshot of volumeId 93738294 at "2009 January 3
17:43:23.228932".

I would like to hear your analysis of why the volumeId space must
grow to 64-bit and how backward compatibility with the existing
clients will be maintained.

Jeffrey Altman


Andrew Deason wrote:
> 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.
>