Bug 5073

Summary:	filename case insensitivity bug
Product:	File System	Reporter:	Max Alekseyev (relf)
Component:	JFS	Assignee:	Dave Kleikamp (shaggy)
Status:	CLOSED CODE_FIX
Severity:	normal
Priority:	P2
Hardware:	i386
OS:	Linux
Kernel Version:	2.6.12	Subsystem:
Regression:	---	Bisected commit-id:
Attachments:	Debug patch jfs_disk.zip : zippped image of a disk with JFS volume Make sure dentry->d_op is initialized for negative dentries

Description Max Alekseyev 2005-08-15 22:06:03 UTC

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.

Comment 1 Dave Kleikamp 2005-08-16 14:05:36 UTC

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.

Comment 2 Dave Kleikamp 2005-08-16 14:10:17 UTC

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

Comment 3 Max Alekseyev 2005-08-16 15:28:52 UTC

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/

Comment 4 Dave Kleikamp 2005-08-17 07:00:32 UTC

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.

Comment 5 Max Alekseyev 2005-08-17 07:27:33 UTC

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

Comment 6 Dave Kleikamp 2005-08-17 07:32:12 UTC

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!

Comment 7 Dave Kleikamp 2005-08-17 08:33:33 UTC

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

Comment 8 Max Alekseyev 2005-08-17 10:42:37 UTC

It does fix the problem! Thanks!

Comment 9 Dave Kleikamp 2005-08-17 11:56:41 UTC

I'll make sure the fix gets into the 2.6.14 kernel