[OpenAFS] Re: Not enough disk space

Andrew Deason adeason@sinenomine.net
Tue, 11 Dec 2012 10:16:50 -0600


On Mon, 10 Dec 2012 21:04:55 +0000
pg@afs.list.sabi.co.UK (Peter Grandi) wrote:

>   * Can OpenAFS partitions be larger than 2TiB? It seems they
>     can be.

Yes.

>   * Are the limits above (31 bits) expressed in bytes or blocks
>     (of what size)?

kilobytes (2^10 bytes).

>   * Does the bug fixed above affect the reporting of free space
>     or the handling of free space

It just fixes the reporting in the server. (But that affects the
behavior in the windows client.)

> in partitions larger than
>     2TiB, or with more than 2TiB of free space?

Both values are reported on the wire, and both have this problem. I
assume the windows client is affected when either one is negative.

>   * Does the bug affect only MS-Windows clients or GNU/Linux
>     clients too?

It's windows-only. But of course, you get negative values back from
things like 'fs lq' regardless.

> Since there is conversion of 64 to 31 bits I guess that OpenAFS
> accounts for space in 64 bit bytes/blocks but reports in 31 bit
> 1KiB blocks.

No, it's all in KiB. The 'conversion' caps the value to the maximum
31-bit integer if the actual value is larger.

> Or put another way, what are the theoretical (in-the-protocol)
> limits for "partition", "partition" free space, "volume"? And
> what are the current implemented limits, disregarding the limits
> of the underlying filesystem?

There are no intentional limits. I think the maximum size is currently
limited by the maximum file size (2^63 bytes, maybe), and the maximum
number of files in a volume (possibly 2^30 or 2^31). While some of that
is because of in-the-protocol limits, they are limits that can be raised
with revisions of the protocol.

There were some stricter limits for 'number of files' before 1.6.1,
since we weren't handling some on-disk i/o properly. And there of course
may be other bugs that we haven't seen yet, limiting file count or file
size, volume size, partition size, etc.

In the current implementation, volumes can also get impractical (or in
some cases, impossible) to 'vos move' et al when they become hundreds of
gigabytes large. But you can always move them by other means.

> BTW as to volumes, looking at 'volsize-caution.pod' the version
> with 1.6.1 says:
> 
>   «Currently, the maximum size of a volume is 2 terabytes (2^31
>   bytes).»
> 
> and more recent versions say:
> 
>   «Currently, the maximum quota for a volume is 2 terabytes
>   (2^41 bytes). Note that this only affects the volume's quota;
>   a volume may grow much larger if the volume quota is disabled.»
> 
> Was there a limit to volume size of 2TiB in 1.6.1 or was it
> always just a quota size limit?

That was just a bug in the documentation; the behavior, limits, etc,
haven't changed.

-- 
Andrew Deason
adeason@sinenomine.net