[LU-220] renaming the cwd of a process on another client exposes some dcache weirdness

• Status: Resolved
• Project: Lustre
• Affects Version/s: Lustre 2.1.0
• Fix Version/s: Lustre 2.3.0
• Type: Bug
• Priority: Minor
• Reporter: John Hammond
• Assignee: nasf (Inactive)
• Resolution: Fixed

Environment

$ uname -r
2.6.18-194.17.1.el5
$ cat /proc/fs/lustre/version
lustre: 2.0.59
kernel: patchless_client
build: jenkins-g3dcb5fb-PRISTINE-2.6.18-194.17.1.el5

• Severity: 3

Description

1. On the first client, create and change to a directory.
   c1$ mkdir /mnt/lustre/dir1; cd /mnt/lustre/dir1
2. Then, on the second, rename that directory:
   c2$ mv /mnt/lustre/dir1 /mnt/lustre/dir2
3. Back on the first client, open(".", O_DIRECTORY...) will fail.
   c1$ ls
   /bin/ls: .: No such file or directory
   c$ pwd
   /mnt/lustre/dir1
   c1$ readlink /proc/$$/cwd
   /mnt/lustre/dir1
   c1$ stat .
   File: `.'
   Size: 4096 Blocks: 8 IO Block: 4096 directory
   Device: 2c54f966h/743766374d Inode: 144115205272502273 Links: 2
   Access: (0755/drwxr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root)
   Access: 2011-04-18 21:12:24.000000000 -0500
   Modify: 2011-04-18 21:12:24.000000000 -0500
   Change: 2011-04-18 21:12:33.000000000 -0500
   c1$ stat ../dir2
   File: `../dir2'
   Size: 4096 Blocks: 8 IO Block: 4096 directory
   Device: 2c54f966h/743766374d Inode: 144115205272502273 Links: 2
   Access: (0755/drwxr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root)
   Access: 2011-04-18 21:12:24.000000000 -0500
   Modify: 2011-04-18 21:12:24.000000000 -0500
   Change: 2011-04-18 21:12:33.000000000 -0500
   c1$ touch foo
   c1$ ls
   ls: .: No such file or directory
   c1$ ls foo
   foo
   c1$ cd ..
4. Now everything appears to be consistent on c1.

Comments

[Andreas Dilger]

This problem still exists with Lustre 2.2.50. I thought it might be related to open-by-FID.

[nasf (Inactive)]

This is the patch:

http://review.whamcloud.com/#change,2493

[nasf (Inactive)]

Patch has been landed to Lustre-2.3

[Alexey Lyashkov]

patch introduce a bug in interop between 2.4 clients and 2.1 servers. see details in LU-3140.

<0>LustreError: 13827:0:(llite_lib.c:1793:ll_update_inode()) ASSERTION( lu_fid_eq(&lli->lli_fid, &body->fid1) ) failed: Trying to change FID [0x200
000400:0x9:0x0] to the [0x200000400:0x8:0x0], inode 144115205255725064/33554436(ffff88005de0caf8)
<0>LustreError: 13827:0:(llite_lib.c:1793:ll_update_inode()) LBUG
<4>Pid: 13827, comm: multiop
<4>
<4>Call Trace:
<4> [<ffffffffa0328895>] libcfs_debug_dumpstack+0x55/0x80 [libcfs]
<4> [<ffffffffa0328e97>] lbug_with_loc+0x47/0xb0 [libcfs]
<4> [<ffffffffa095a985>] ll_update_inode+0x325/0x880 [lustre]
<4> [<ffffffffa0967b3d>] ll_prep_inode+0x19d/0xf60 [lustre]
<4> [<ffffffffa03392c1>] ? libcfs_debug_msg+0x41/0x50 [libcfs]
<4> [<ffffffffa094dab6>] ll_intent_file_open+0x566/0xfd0 [lustre]
<4> [<ffffffffa0975930>] ? ll_md_blocking_ast+0x0/0x750 [lustre]
<4> [<ffffffffa094e5a8>] ll_lov_setstripe_ea_info+0x88/0x2d0 [lustre]
<4> [<ffffffffa0950c35>] ll_lov_setstripe+0x95/0x5a0 [lustre]
<4> [<ffffffffa095282a>] ll_file_ioctl+0xa9a/0x26b0 [lustre]
<4> [<ffffffff8104757c>] ? __do_page_fault+0x1ec/0x480
<4> [<ffffffff81194fb2>] vfs_ioctl+0x22/0xa0
<4> [<ffffffff8119547a>] do_vfs_ioctl+0x3aa/0x580
<4> [<ffffffff811956d1>] sys_ioctl+0x81/0xa0
<4> [<ffffffff8100b072>] system_call_fastpath+0x16/0x1b

[Alexey Lyashkov]

easy replicated with CLIENTONLY=yes CLIENTMODSONLY=yes ONLY=27B MGSNID=192.168.69.5@tcp sh sanity.sh

i don't know - why it's don't hit on Intel interoperability testing because it's hit on each run.