Hi Thomas,

On Aug 15, 2012, at 13:51 , Thomas L. Koppe <[log in to unmask]> wrote:

> in the mean while we builded the kmod-openafs rpm against the kernel 2.6.32-279.2.1.el6 and now we've no problems anymore. We're testing it now for while.

is your cache on ext4? The old module seems to work for me when I use ext3 for the cache.

I wonder whether the problem is related to this: http://joejulian.name/blog/glusterfs-bit-by-ext4-structure-change/

All the same, it still means that those handy kmods cannot be used for packaging the openafs client. I guess it's back to kernel-module-openafs-`uname -r` .

Best regards,
	Stephan

> Am 15.08.2012 11:38, schrieb Stephan Wiesand:
>> On Aug 15, 2012, at 09:41 , "Thomas L. Koppe"<[log in to unmask]>  wrote:
>> 
>>> we have some problems with the new kernels (2.6.32-279, 2.6.32-279.1.1, 2.6.32-279.2.1) and openafs-1.6.1-112.sl6 on 32bit systems. It's the same problem on SL_6.2_X86 and SL6.3_X86. On servers with just a few installed RPMs everything works fine. On systems with a full paket installation we can't read any files in afs, which are bigger than some kbytes. On x86_64 systems we have no problems.
>> 
>> 
>> ouch. I can reproduce this on my test VM. Reading processes just hang in D+ state, but are interruptible, right?
>> 
>> I rebuilt the module against 2.6.32-279.1.1, and that build works for me. Could you please try
>> 
>> http://www-zeuthen.desy.de/~wiesand/SL6/i686/kmod-openafs-1.6.1-112.sl6.279.1.1.i686.rpm ?
>> 
>> Installing this will probably cause the same problem with older kernels you still have installed. If you want to keep both functional, rm /lib/modules/.../weak-updates/openafs/openafs.ko , extract the new module with rpm2cpio|cpio -iv, copy it to an appropritae place (say /lib/modules/.../kernel/fs), and run depmod -a 2.6.32-279.1.1.el6 . Then cross fingers and reboot.

-- 
Stephan Wiesand
DESY - DV -
Platanenallee 6
15732 Zeuthen, Germany