Re: [OpenAFS] /var/cache/openafs on btrfs
On 03/02/2016 01:54 AM, Fred Drueck wrote: 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 I've been using an ext4 partition for my cache for years now. There are several additional optimizations that can be done, but the only one I remember at the moment is to create the filesystem without a journal. Because ext4 natively allocates extents, these can directly map to cache chunks. I've been happy. Dale Pontius -- Dale Pontius Senior Engineer IBM Corporation Phone: (802) 769-6850 Tie-Line: 446-6850 email: pont...@us.ibm.com This e-mail and its attachments, if any, may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply e-mail and delete all copies of this message from your system without copying it and notify sender of the misdirection by reply e-mail. ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
RE: [OpenAFS] /var/cache/openafs on btrfs
ZFS requires specific tuning for use as a cache partition; otherwise, its allocation size interacts poorly with the allocation size of cache chunks, IIRC. I'd imagine something similar is true of btrfs, but I know even less about btrfs implementation details than ZFS. -Original Message- From: openafs-info-ad...@openafs.org [mailto:openafs-info-ad...@openafs.org] On Behalf Of Benjamin Kaduk Sent: Wednesday, May 4, 2016 10:21 PM To: Fred Drueck <fdru...@uic.edu> Cc: openafs-info@openafs.org Subject: Re: [OpenAFS] /var/cache/openafs on btrfs On Wed, 2 Mar 2016, Fred Drueck wrote: > 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 long timeouts are expected when all the db servers are inaccessible. > 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 think there is some chance, but this is not an area I've looked into for quite some time, and may be misremembering. I do have some recollection that ZFS behaves poorly for a cache partition, and given btrfs's similarities to ZFS, would not really recommend it either, absent further research. -Ben ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info :�� T���)b� b�өzpJ)ߢ�^��좸!��l��b��(���~�+Y���b�ا~�~ȧ~
Re: [OpenAFS] /var/cache/openafs on btrfs
On Wed, 2 Mar 2016, Fred Drueck wrote: > 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 long timeouts are expected when all the db servers are inaccessible. > 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 think there is some chance, but this is not an area I've looked into for quite some time, and may be misremembering. I do have some recollection that ZFS behaves poorly for a cache partition, and given btrfs's similarities to ZFS, would not really recommend it either, absent further research. -Ben ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
[OpenAFS] /var/cache/openafs on btrfs
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
