[OpenAFS] Not enough disk space

[Jeffrey Altman]

The bug fixed by the referenced patch set is specifically related to the rep=
orting of partition sizes and free space by the file server to the client.  T=
hese sizes are reported in 1KiB units.  The field used to report the sizes i=
s a signed 32-bit field.  If the value being reported is greater than 2^31 t=
hen it may be interpreted as negative or a small positive value.  This is a p=
articular problem for the 1.7.x windows clients which expose AFS volumes as d=
istinct volumes to the IFS layer and which perform checks on extending write=
s to prevent applications from writing data into the windows page cache whic=
h could not possibly be stored in the volume on the file server.

However the bug is not limited to Windows and impacts any cache manager or t=
ool the queries the volume status information.

The patch set will be included in 1.6.2pre1 which will be announced shortly.=


Jeffrey Altman


On Dec 10, 2012, at 4:04 PM, pg@afs.list.sabi.co.UK (Peter Grandi) wrote:

> [ ... ]
>=20
>>> 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.
>=20
>> This has been discussed on the list before.
>=20
>>>> For 1.6.1, ...
>=20
>>>> 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.
>=20
> 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):
>=20
>  * Can OpenAFS partitions be larger than 2TiB? It seems they
>    can be.
>=20
>  * Are the limits above (31 bits) expressed in bytes or blocks
>    (of what size)?
>=20
>  * 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?
>=20
>  * Does the bug affect only MS-Windows clients or GNU/Linux
>    clients too?
>=20
> 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.
>=20
> 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?
>=20
> BTW as to volumes, looking at 'volsize-caution.pod' the version
> with 1.6.1 says:
>=20
>  =C2=ABCurrently, the maximum size of a volume is 2 terabytes (2^31
>  bytes).=C2=BB
>=20
> and more recent versions say:
>=20
>  =C2=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.=C2=BB
>=20
> Was there a limit to volume size of 2TiB in 1.6.1 or was it
> always just a quota size limit?
> _______________________________________________
> OpenAFS-info mailing list
> OpenAFS-info@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-info