(From Jim Garlick) I'm playing with v9fs a bit and found some odd behavior with getcwd. (Nice job getting v9fs into the 2.6.14 - the downside is people will find it and use it :-) Here is my setup: * Fedora Core 3 box running 2.6.9-1.667 kernel, runs u9fs (grabbed from v9fs project cvs today) via xinetd. * Fedora Core 4 box running 2.6.14-1.1637_FC4 kernel mounts the first box's filesystem with "mount -t 9P <ip of first box> /w". u9fs starts up on the first box running as nobody. Now if I cd into a subdirectory of the mounted 9P file system - not /w but something under that - and run /bin/pwd, it works. If I do an ls, then /bin/pwd again, it doesn't and an strace shows getcwd returning ENOENT. If I cd to .. and then back again, /bin/pwd works. Another ls, and then /bin/pwd gets ENOENT.
Here's a funny twist: bash-2.05b# cd /mnt/9 bash-2.05b# cd / bash-2.05b# cd /mnt/9/tmp bash-2.05b# pwd /mnt/9/tmp bash-2.05b# ls u9fs.log bash-2.05b# pwd /mnt/9/tmp bash-2.05b# ls u9fs.log bash-2.05b# pwd /mnt/9/tmp bash-2.05b# ls u9fs.log bash-2.05b# pwd /mnt/9/tmp bash-2.05b# /bin/pwd /bin/pwd: cannot get current directory: No such file or directory With debug on: bash-2.05b# /bin/pwd /mnt/9/tmp bash-2.05b# ls -- v9fs_fid_get_created (123): dentry: tmp (c00000000745ae08) -- v9fs_fid_get_created (123): return 0000000000000000 -- v9fs_fid_lookup (123): dentry: tmp (c00000000745ae08) -- v9fs_t_walk (123): fid 1 newfid 2 wname '<NULL>' -- v9fs_t_open (123): fid 2 mode 0 -- v9fs_fid_lookup (123): dentry: tmp (c00000000745ae08) -- v9fs_t_stat (123): fid 1 -- v9fs_t_read (123): fid 2 offset 0x0 count 0x2310 -- v9fs_t_read (123): fid 2 offset 0x9b count 0x2310 -- v9fs_t_read (123): fid 2 offset 0x9b count 0x2310 -- v9fs_t_clunk (123): fid 2 u9fs.log bash-2.05b# /bin/pwd /bin/pwd: cannot get current directory: No such file or directory (note the lack of any v9fs debug on the pwd's) -- it's definitely something screwy with the dcache. I'll have to instrument with some more debug. Potentially this is the motivation I need to rewrite the fid management stuff (which is behind the aggressive dcache invalidation).
Upping priority as it made Andrew's issues list. Will try and resolve this in the next few days.
I'm writing up implementation notes for the fix in swik: http://swik.net/FID-mapping-rework I think I have a workable scenerio but it'll take me a few more days to implement and try it out.
fixed in v9fs-devel.git tree on kernel.org