[AFS3-std] Re: [RPC Request] 64-bit volume IDs, quotas, and block
usages
Derrick Brashear
shadow@gmail.com
Mon, 22 Jun 2009 11:35:02 -0400
--0016364ed6501fc0a5046cf19e3a
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
On Mon, Jun 22, 2009 at 11:14 AM, Andrew Deason <adeason@sinenomine.net>wrote:
> On Mon, 22 Jun 2009 00:28:48 -0400
> Derrick Brashear <shadow@gmail.com> wrote:
>
> > Backwards compatibility should not be a barrier to deploying new
> > RPCs. It should be a barrier to allowing the addition space to be
> > used in environments which do not wish to break said compatibility.
> > The least common denominator should not be allowed to hold back sites
> > wanting or needing more.
> >
> > For sites that cannot change clients, disallowing consumption of IDs
> > beyond the current limit is an easy answer. If I want to use more,
> > and am willing to, for my site, do the upgrades or make some volumes
> > unusable to old clients, I don't see why I should be restrained from
> > doing so.
>
> This was my intention when submitting this. I did not have a plan or
> scheme in mind for backwards compatibility; if a site wants to support
> legacy clients, I imagined they would simply not use volume IDs above
> the 32-bit barrier. Implementations would/should have some kind of
> administrative switch that administrators would explicitly have to turn
> on to enable them.
>
> I'd also like to note that the simple 32->64 conversion isn't the only
> way to do this. I've been told there's at least one other proposal in
> the works for extending the volume ID-space which conflicts with what I
> wrote. I'll see if I can help get it on this list soon.
>
If said proposal is only useful for snapshots (additional volumes in a
group, with timestamp differentiation, or that ilk, which I've proposed
before) it doesn't solve the issue of people legitimately needing more than
2^32 volumes.
--
Derrick
--0016364ed6501fc0a5046cf19e3a
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<br><br><div class=3D"gmail_quote">On Mon, Jun 22, 2009 at 11:14 AM, Andrew=
Deason <span dir=3D"ltr"><<a href=3D"mailto:adeason@sinenomine.net">ade=
ason@sinenomine.net</a>></span> wrote:<br><blockquote class=3D"gmail_quo=
te" style=3D"border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt=
0.8ex; padding-left: 1ex;">
<div class=3D"im">On Mon, 22 Jun 2009 00:28:48 -0400<br>
Derrick Brashear <<a href=3D"mailto:shadow@gmail.com">shadow@gmail.com</=
a>> wrote:<br>
<br>
> Backwards compatibility should not be a barrier to deploying new<br>
> RPCs. It should be a barrier to allowing the addition space to be<br>
> used in environments which do not wish to break said compatibility.<br=
>
> The least common denominator should not be allowed to hold back sites<=
br>
> wanting or needing more.<br>
><br>
> For sites that cannot change clients, disallowing consumption of IDs<b=
r>
> beyond the current limit is an easy answer. If I want to use more,<br>
> and am willing to, for my site, do the upgrades or make some volumes<b=
r>
> unusable to old clients, I don't see why I should be restrained fr=
om<br>
> doing so.<br>
<br>
</div>This was my intention when submitting this. I did not have a plan or<=
br>
scheme in mind for backwards compatibility; if a site wants to support<br>
legacy clients, I imagined they would simply not use volume IDs above<br>
the 32-bit barrier. Implementations would/should have some kind of<br>
administrative switch that administrators would explicitly have to turn<br>
on to enable them.<br>
<br>
I'd also like to note that the simple 32->64 conversion isn't th=
e only<br>
way to do this. I've been told there's at least one other proposal =
in<br>
the works for extending the volume ID-space which conflicts with what I<br>
wrote. I'll see if I can help get it on this list soon.<br></blockquote=
><div><br>If said proposal is only useful for snapshots (additional volumes=
in a group, with timestamp differentiation, or that ilk, which I've pr=
oposed before) it doesn't solve the issue of people legitimately needin=
g more than 2^32 volumes. <br>
</div></div><br clear=3D"all"><br>-- <br>Derrick<br>
--0016364ed6501fc0a5046cf19e3a--