Distribution: debian-amd64 Steps to reproduce: run the following shell script from some directory on JFS volume which is insensitive to case of filenames. ==== start of testcase.sh ==== touch testfile mv testfile Testfile mkdir mydir mv testfile mydir/Testfile ls mv mydir/Testfile ./ ==== end of testcase.sh ==== A sample output is $ sh testcase.sh mv: `testfile' and `Testfile' are the same file mydir mv: `mydir/Testfile' and `./Testfile' are the same file Please note that the last error should not happen. According to the output of "ls" command, there no "./testfile" or "./Testfile" file in the current directory. So the command "mv mydir/Testfile ./" should succeed but it does not. Somehow JFS reports that there is file "./Testfile" in the current directory while there is no such file.
Hmm. I can't reproduce the problem on a 2.6.12 i386 kernel. I also tried a 2.6.13-rc4-mm1 ppc64 kernel (as the only 64-bit hardware I have easy access to). From the behavior you report, it seems that testfile and Testfile each have a separate entry in the dcache. Moving testfile would only invalidate its entry, leaving an invalid entry for Testfile, which would explain the failure of the last mv. But this shouldn't happen. This used to be a problem before 2.6.8, but now jfs defines jfs_ci_dentry_operations which should force testfile and Testfile to have the same dcache entry. I'm not sure why it's not working for you. I have a small debug patch that may help explain what's going on.
Created attachment 5651 [details] Debug patch If you could please build jfs.o with this patch, and with CONFIG_JFS_DEBUG defined, then modify your test case to do: echo 3 > /proc/fs/jfs/loglevel touch testfile mv testfile Testfile mkdir mydir mv testfile mydir/Testfile ls mv mydir/Testfile ./ echo 2 > /proc/fs/jfs/loglevel dmesg should contain some info that may help me figure out what's going on. You'll need to be root to write to /proc/fs/jfs/loglevel. Thanks
Created attachment 5652 [details] jfs_disk.zip : zippped image of a disk with JFS volume With your patch in my syslog a see a single line JFS: nTxBlock = 4025, nTxLock = 32201 The problem might be related to the fact that my JFS volumes were created under OS/2. I've created a small JFS volume that should demostrate the problem. Mount it with mount -t jfs -o loop,offset=32256 jfs.hdd /mnt/mountpoint/ and run testcase.sh from /mnt/mountpoint/
Even using your disk image, I was unable to recreate your error on my i386 machine. Just to make sure, you did add "echo 3 > /proc/fs/jfs/loglevel", etc. to your test script, right? Assuming you did, this could mean that for some reason, jfs_ci_dentry_operations are not being used at all. I'm not sure why not.
I've just noticed that the bug does not appear if the script is run from the root of the disk. I've also successfully reproduced the bug under debian-i386, so it is *not* 64-bit specific. My screenshot: tpt22:/tmp# mkdir jfs tpt22:/tmp# unzip jfs_disk.zip Archive: jfs_disk.zip inflating: jfs.hdd tpt22:/tmp# mount -t jfs -o loop,offset=32256 jfs.hdd ./jfs tpt22:/tmp# cd jfs tpt22:/tmp/jfs# sh ../testcase.sh mv: `testfile' and `Testfile' are the same file mydir tpt22:/tmp/jfs# mkdir ttt tpt22:/tmp/jfs# cd ttt/ tpt22:/tmp/jfs/ttt# sh ../../testcase.sh mv: `testfile' and `Testfile' are the same file mydir mv: `mydir/Testfile' and `./Testfile' are the same file
OK! I've been running from the root of the disk. Now I am able to recreate the problem. I can debug this without your help now. I'll let you know what I find out. Thanks!
Created attachment 5657 [details] Make sure dentry->d_op is initialized for negative dentries Please try this patch. I think it will fix the problem
It does fix the problem! Thanks!
I'll make sure the fix gets into the 2.6.14 kernel