[OpenAFS] dir name length dependent 'File too large' error

Derrick Brashear shadow@gmail.com
Thu, 10 Jan 2008 09:45:02 -0500


------=_Part_33951_18690044.1199976302905
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

On Jan 10, 2008 9:40 AM, Matthias Witte <witte@netzquadrat.de> wrote:

>
> I have no explaination, why we get a file too large error in this case:
>
> /afs/foo.org/webfax/b
>
>        is a volume without quota containing 31707 subdirectories, each
> name of
>        which has 32 characters length.
>

31707 is why. You're out of space for more directory entries.


>
>        $ fs examine /afs/foo.org/webfax/b
>        File /afs/foo.org/webfax/b (536871032.1.1) contained in volume
> 536871032
>        Volume status for vid = 536871032 named wfax.b
>        Current disk quota is unlimited
>        Current blocks used are 13884367
>        The partition has 1133660144 blocks available out of 1302880632
>
>
> Now if I try to create a directory with a name longer than 15 characters I
> get
> a 'file too large' error.
>
> However if the name is only 15 characters long no error occurs, I can at
> least create 15 more directories (i haven't tried how much more).
>

 http://www.openafs.org/pipermail/openafs-info/2002-September/005812.html

We have a plan to update this, but no update is available at this time.


> The client and server version is 1.4.2, the systems are running the amd64
> flavour of debian etch, that is the debian maintainer has backported and
> applied several patches from later releases and bugfixes.
>
> Which limit am I hitting here and is there a way to resolve this problem?
>
>

------=_Part_33951_18690044.1199976302905
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

<br><br><div class="gmail_quote">On Jan 10, 2008 9:40 AM, Matthias Witte &lt;<a href="mailto:witte@netzquadrat.de">witte@netzquadrat.de</a>&gt; wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>I have no explaination, why we get a file too large error in this case:<br><br>/afs/foo.org/webfax/b<br><br> &nbsp; &nbsp; &nbsp; &nbsp;is a volume without quota containing 31707 subdirectories, each name of<br> &nbsp; &nbsp; &nbsp; &nbsp;which has 32 characters length.
<br></blockquote><div><br>31707 is why. You&#39;re out of space for more directory entries. <br>&nbsp;<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br> &nbsp; &nbsp; &nbsp; &nbsp;$ fs examine /afs/foo.org/webfax/b<br> &nbsp; &nbsp; &nbsp; &nbsp;File /afs/foo.org/webfax/b (536871032.1.1) contained in volume 536871032<br> &nbsp; &nbsp; &nbsp; &nbsp;Volume status for vid = 536871032 named wfax.b<br> &nbsp; &nbsp; &nbsp; &nbsp;Current disk quota is unlimited
<br> &nbsp; &nbsp; &nbsp; &nbsp;Current blocks used are 13884367<br> &nbsp; &nbsp; &nbsp; &nbsp;The partition has 1133660144 blocks available out of 1302880632<br><br><br>Now if I try to create a directory with a name longer than 15 characters I get<br>a &#39;file too large&#39; error.
<br><br>However if the name is only 15 characters long no error occurs, I can at<br>least create 15 more directories (i haven&#39;t tried how much more).<br></blockquote><div><br>&nbsp;<a href="http://www.openafs.org/pipermail/openafs-info/2002-September/005812.html">
http://www.openafs.org/pipermail/openafs-info/2002-September/005812.html</a><br><br>We have a plan to update this, but no update is available at this time.<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>The client and server version is 1.4.2, the systems are running the amd64<br>flavour of debian etch, that is the debian maintainer has backported and<br>applied several patches from later releases and bugfixes.<br><br>
Which limit am I hitting here and is there a way to resolve this problem?<br><br></blockquote></div><br>

------=_Part_33951_18690044.1199976302905--