[OpenAFS] /var/cache/openafs on btrfs

[Fred Drueck]

--001a113dea3c776048052d0b5b70
Content-Type: text/plain; charset=UTF-8

Hello Everyone,

According to the OpenAFS admin FAQ, it appears that the officially
supported file systems for the disk cache are:

ext2
ext3
hfs (HP-UX)
xfs (at least on IRIX 6.5)
ufs (Solaris, ?Tru64Unix)

which is clearly out of date, since there is a working implementation for
OS X that runs on top of HFS+

For some time I've been fearlessly using both ext4 and btrfs (on Linux, as
you might infer) as the backing storage for my AFS client cache.

I have noticed some fairly rare issues with the clients if all file/db
servers (in our cell the same machines) become unavailable.  The '/afs'
mount becomes un-accessible and attempts to access files often result in
very long timeouts.  I've always been able to fix things by somehow
shutting down the client (in the worst case by physical power-off and
reboot into single user mode) and deleting the cache.

Is there some chance that this is because I've been causing these problems
by using un-supported file-systems as the backing storage for the client
cache?

I'm using fairly recent versions of the client, namely the version packaged
for debian-squeeze, debian-wheezy, ubuntu 14.04, and a very recent release
on Arch Linux.

e.g.

1.6.9-2+deb8u4~bpo70+1
Version: 1.4.12.1+dfsg-4+squeeze4
Version: 1.6.7-1ubuntu1.
openafs 1.6.14.1-1

For the most part, though, I haven't had many issues.  Does anyone know any
updated info on what the supported client filesystems are?

Thanks!
-Fred

--001a113dea3c776048052d0b5b70
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hello Everyone,<div><br></div><div>According to the OpenAF=
S admin FAQ, it appears that the officially supported file systems for the =
disk cache are:</div><div><br></div><div><div>ext2</div><div>ext3</div><div=
>hfs (HP-UX)</div><div>xfs (at least on IRIX 6.5)</div><div>ufs (Solaris, ?=
Tru64Unix)</div></div><div><br></div><div>which is clearly out of date, sin=
ce there is a working implementation for OS X that runs on top of HFS+</div=
><div><br></div><div>For some time I&#39;ve been fearlessly using both ext4=
 and btrfs (on Linux, as you might infer) as the backing storage for my AFS=
 client cache.</div><div><br></div><div>I have noticed some fairly rare iss=
ues with the clients if all file/db servers (in our cell the same machines)=
 become unavailable.=C2=A0 The &#39;/afs&#39; mount becomes un-accessible a=
nd attempts to access files often result in very long timeouts.=C2=A0 I&#39=
;ve always been able to fix things by somehow shutting down the client (in =
the worst case by physical power-off and reboot into single user mode) and =
deleting the cache.</div><div><br></div><div>Is there some chance that this=
 is because I&#39;ve been causing these problems by using un-supported file=
-systems as the backing storage for the client cache?</div><div><br></div><=
div>I&#39;m using fairly recent versions of the client, namely the version =
packaged for debian-squeeze, debian-wheezy, ubuntu 14.04, and a very recent=
 release on Arch Linux.</div><div><br></div><div>e.g.</div><div><br></div><=
div>1.6.9-2+deb8u4~bpo70+1<br></div><div>Version: 1.4.12.1+dfsg-4+squeeze4<=
br></div><div>Version: 1.6.7-1ubuntu1.</div><div>openafs 1.6.14.1-1<br></di=
v><div><br></div><div>For the most part, though, I haven&#39;t had many iss=
ues.=C2=A0 Does anyone know any updated info on what the supported client f=
ilesystems are?</div><div><br></div><div>Thanks!</div><div>-Fred</div><div>=
<br></div></div>

--001a113dea3c776048052d0b5b70--