[OpenAFS] Not enough disk space
Mon, 10 Dec 2012 16:44:39 -0500
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.=
On Dec 10, 2012, at 4:04 PM, email@example.com.UK (Peter Grandi) wrote:
> [ ... ]
>>> 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 <firstname.lastname@example.org>
>>>> 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
> * 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:
> =C2=ABCurrently, the maximum size of a volume is 2 terabytes (2^31
> and more recent versions say:
> =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
> 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