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

Jeffrey Altman jaltman@secure-endpoints.com
Sun, 21 Jun 2009 10:43:25 -0400


Russ Allbery wrote:
> Jeffrey Altman <jaltman@secure-endpoints.com> writes:
>
>> 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.
>
> windlord:~> vos examine ls.trip.www-liv1
> ls.trip.www-liv1                 2005330094 RW       1793 K  On-line
>     afssvr36.Stanford.EDU /vicepg 
>     RWrite 2005330094 ROnly          0 Backup 2005330096 
>     MaxQuota      10000 K 
>     Creation    Wed Jun 17 19:59:22 2009
>     Copy        Wed Jun 17 19:59:22 2009
>     Backup      Sat Jun 20 01:25:48 2009
>     Last Update Wed Jun 17 20:01:24 2009
>     10 accesses in the past day (i.e., vnode references)
>
>     RWrite: 2005330094    Backup: 2005330096
>     number of sites -> 1
>        server afssvr36.Stanford.EDU partition /vicepg RW Site 
>
> It's not feeling particularly spacious to us, although that problem
> would be solved in specific implementations by allowing volume IDs to
> wrap.  (I think we looked at this a while back and decided that they
> don't currently in OpenAFS.)
>
> There was an old bug in Transarc AFS that could cause one to consume a
> spectacular number of volume IDs.  I've heard of other sites with the
> same problem.
>   
The problem as I see it is that the volumeId name space is poorly
managed.  Changes to the name space
management are entirely implementation dependent and do not require
changes to the RPCs.   Even
assuming that replacing the volumeId allocation algorithm required
changes to the server RPCs, that
is much easier to deploy than changes affecting the clients.

Jeffrey Altman