On Wed, Aug 29, 2012 at 11:21 AM, Stephan Wiesand <[email protected]> wrote: > Hi All, > > this is just a question. I'm not asserting an openafs bug. > > Since SL6, we have we have been using "kABI tracking kmods" for installing > the OpenAFS kernel module on clients. For full information on this mechanism, > see http://people.redhat.com/jcm/el6/dup/docs/dup_book.pdf . In short, you > only have to compile and install the module once, and it will be used with > future kernels as long as it doesn't use parts of the ABI that changed. > > Trying this may have been stupid in the first place. If so, happy bashing :-) > > But in practice, it has worked perfectly for a long time. The modules built > against the EL6 GA kernel (2.6.32-71.el6) work fine with every released > kernel up to the latest EL6.2 kernels (2.6.32-220.23.1.el6), on both 32-bit > and 64-bit systems. > > But with the EL6.3 update (2.6.32-279.el5), something changed that broke at > least the interface to the 32-bit module. The symptoms are reads getting > stuck at the very beginning, except for very small files. The reads can be > interrupted, but the client can no longer be stopped cleanly.
Anything interesting in the syslog when this occurs? > Using a module built against the 6.3 kernel with pre-6.3 ones has worse > effects. BUGs, panics, spontaneous reboots. > > All this was only observed on 32-bit systems, and only if the cache is on > ext4. I have a suspicion that it might be related to a change described here: > http://joejulian.name/blog/glusterfs-bit-by-ext4-structure-change/ . Quote: > << a patch against ext4 to "return 32/64-bit dir name hash according to usage > type". Prior to that, ext2/3/4 would return a 32-bit hash value from > telldir()/seekdir() [. . .] That patch was for kernel v3.3-rc2. To make > things more fun, [. . .] merged in that patch in 2.6.32-268.el6 >> > > The direct link to the patch is > http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=commit;h=d1f5273e9adb40724a85272f248f210dc4ce919a > . > > Does anyone familiar withe the openafs module's inner workings see whether > that patch would have the effects described above, on 32-bit systems only? > > Thanks a lot in advance for any insights. > > Stephan Offhand I don't see anything in that change that should affect openafs. Within the kernel module each cache file is looked up up individually with a full path that it receives from afsd - the directory scanning is done by afsd in user space using readdir. The lookup returns a dentry which is then converted to a file handle by the underlying file system's own conversion function. The file handles for all cache files are stored in memory by the module. When a file is used, the file handle is converted to a dentry with the fs's conversion function, and the file is opened with dentry_open. Any other changes to ext4 in that update? Does the module work correctly on this system, with ext4, if it is recompiled? Marc _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
