[revisiting this thread]
On 6/29/18 10:43 AM, Kevin Wolf wrote:
Am 29.06.2018 um 17:22 hat Eric Blake geschrieben:
On 06/29/2018 03:44 AM, Kevin Wolf wrote:
Am 28.06.2018 um 21:07 hat Eric Blake geschrieben:
Match our code to the spec change in the previous patch - there's
no reason for the r
On Fri, Jun 29, 2018 at 10:22:22AM -0500, Eric Blake wrote:
> On 06/29/2018 03:44 AM, Kevin Wolf wrote:
> > Am 28.06.2018 um 21:07 hat Eric Blake geschrieben:
> > > Match our code to the spec change in the previous patch - there's
> > > no reason for the refcount table to allow larger offsets than
Am 29.06.2018 um 17:22 hat Eric Blake geschrieben:
> On 06/29/2018 03:44 AM, Kevin Wolf wrote:
> > Am 28.06.2018 um 21:07 hat Eric Blake geschrieben:
> > > Match our code to the spec change in the previous patch - there's
> > > no reason for the refcount table to allow larger offsets than the
> > >
On 06/29/2018 03:44 AM, Kevin Wolf wrote:
Am 28.06.2018 um 21:07 hat Eric Blake geschrieben:
Match our code to the spec change in the previous patch - there's
no reason for the refcount table to allow larger offsets than the
L1/L2 tables.
What about internal snapshots? And anyway, because of t
Am 28.06.2018 um 21:07 hat Eric Blake geschrieben:
> Match our code to the spec change in the previous patch - there's
> no reason for the refcount table to allow larger offsets than the
> L1/L2 tables.
What about internal snapshots? And anyway, because of the metadata
overhead, the physical image
Match our code to the spec change in the previous patch - there's
no reason for the refcount table to allow larger offsets than the
L1/L2 tables. In practice, no image has more than 64PB of
allocated clusters anyways, as anything beyond that can't be
expressed via L2 mappings to host offsets.
Sugg
