[OpenAFS] Not enough disk space

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


[ ... ]

>> most of our file servers exceed the magical limit of 2TiB per
>> partition.  When I try to save a file via MS Word 2010 on a
>> volume there, an error is shown "There is not enough disk
>> space. Free enough disk space, and the try again." It seems
>> to be related to the free disk blocks on the partition
>> exceeding 2^31 . I'm not quite sure, if my users started
>> using MS Word for files on those partitions recently of if
>> the Windows AFS Client's behaviour changed during an upgrade.

> This has been discussed on the list before.

>>> For 1.6.1, ...

>>> commit a64864529d1fca2b5a3f4d21ec598982be335368
>>> Author: Jeffrey Altman <jaltman@your-file-system.com>
>>> Date:   Mon Apr 2 22:35:41 2012 -0400
>>>     viced: AFSDisk, AFSFetchVolumeStatus Int31 PartSize
>>>     The AFSDisk and AFSFetchVolumeStatus structures use signed
>>>     32-bit integers for representation partition size and
>>>     available blocks.  RoundInt64ToInt31() should be used instead
>>>     of RoundInt64ToInt32() when assigning their values.

Please help me understand what this implies, as I am aware that
OpenAFS (or more generally I think AFS) volumes can be larger
than 2TiB,unless they are subject to quota (which are limited to
2TiB):

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

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

  * Does the bug fixed above affect the reporting of free space
    or the handling of free space in partitions larger than
    2TiB, or with more than 2TiB of free space?

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

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.

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?

BTW as to volumes, looking at 'volsize-caution.pod' the version
with 1.6.1 says:

  =ABCurrently, the maximum size of a volume is 2 terabytes (2^31
  bytes).=BB

and more recent versions say:

  =ABCurrently, 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.=BB

Was there a limit to volume size of 2TiB in 1.6.1 or was it
always just a quota size limit?